[fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss
Jonas Maebe
jonas.maebe at elis.ugent.be
Wed May 11 15:14:45 CEST 2016
Graeme Geldenhuys wrote on Wed, 11 May 2016:
> On 2016-05-11 13:27, Jonas Maebe wrote:
>> If you change the string to unicodestring (since
>> FPC 2.6.4 does not know {$modeswitch unicodestring}), you should get
>> the same results in FPC 2.6.4 and FPC 3.x
>
> No, because FPC 2.6.4 doesn't do automatic encoding conversions.
FPC 2.6.x and FPC 3.0 perform exactly the same automatic encoding
conversions when assigning that ansistring property to a unicodestring
variable in your test program.
> I would
> first have to add UTF8Decode() calls wherever I assign known UTF-8 data
> to a UnicodeString.
If you do the same in FPC 3.0, you will get exactly the same results
as in FPC 2.6.x.
> With FPC 2.6.4 I never use UnicodeString. Like with Lazarus LCL, I use
> AnsiString with a UTF-8 payload. I define a new type which I use in my
> application to remind me of that fact.
First, you start with a warning about how no one should use FPC 3.0
with the String type, because it completely changes the behaviour
compared to FPC 2.6.x due to automatic conversions in the RTL and FCL.
When it is clear that is not true, you are now saying that the
behaviour of FPC 3.0 is different to FPC 2.6.x if you compile
different code with each one.
Well, yes: if you use different code in FPC 2.6.x and FPC 3.x, then
you can indeed get very different behaviour.
Jonas
More information about the fpc-pascal
mailing list