Graeme Geldenhuys wrote on Wed, 11 May 2016:
My test program under FPC 2.6.4 doesn't give problems. It's when that same program is compiled under FPC 3.0.0 that it does. All due to String (and thus AnsiString) changing its encoding based on the running environment.
In FPC 2.6.x, if you use a widestring manager (such as cwstring), the code page of shortstring/ansistring/pchar /also/ depends on the running environment, in fact in exactly the same way as in FPC 3.x. The main thing that is new in FPC 3.x, is that instead of the RTL assuming that all ansistring contents are always encoded in this code page, we now explicitly attach the code page information in a hidden field of the ansistring structure (so different ansistrings can have different encodings, but the default for plain ansistrings remains exactly the same).
With FPC 2.6.4 compiled programs, no matter the environment (UTF-8 or Latin-1), my test program behaves the same.
As I asked before: did you change "String" to "Unicodestring" when compiling under FPC 2.6.4? As mentioned before, {$modeswitch unicodestrings} is a new feature in FPC 3.0 and is ignored by FPC 2.6.4 (you will get a warning about this when compiling with FPC 2.6.4, but not an error).
Jonas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
