[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