Warning not to use the "String" type with FPC 3.x

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
Hi,

I really think the FPC team should make it blatantly clear that the
usage of the aliased "String" type should not be used any more with FPC
3.x.  It turn I think major alarm bells should start ringing when
AnsiString type is used too.

Both are fraught with dangers of loosing data. I've long given up with
the UTF-16 vs UTF-8 debate. FPC has now made an even bigger mess than
Delphi 2009 did. I've now reached the point where I think - just switch
the RTL to UTF-16 only so we can stop loosing data during string
conversions! Java does it, C# does it, Delphi 2009 does it. It's time
FPC stops trying to please everybody, and switch too.

My reasoning for the above. Data loss during string conversions!

1. The "String" type has too many meanings. I recommend you simply stop
   using it in your code. Instead, use the exact type you really mean or
   support in your application.

2. AnsiString in FPC 3.x is now code page enabled, and can have many
   different meanings.
   There is no guarantee that assigning a UTF8String or UnicodeString
   to a AnsiString is safe. On some systems the AnsiString might
   default to a UTF-8 or UTF-16 encoding which is fine, but importantly,
   on other systems in might default to something else, and then you
   simply loose data during the conversion. What makes it even worse,
   is that the default encoding for AnsiString is determined at
   runtime, so the programmer is completely helpless in preventing
   this. This issue is also not specific to only certain operating
   systems. You can have a Linux or FreeBSD system that defaults to
   a non-Unicode type code page, yet the Linux system running right
   next to that one could have been set up to use a UTF-8 code page.
   Same for Windows platforms.

FPC should seriously start ringing those alarm bells, as many programs
compiled with FPC 3.x are bound to hit these errors (BUGS). Valuable
data could get corrupted.

To all programmers, start using UnicodeString or UTF8String types only,
and everywhere!

Regards,
  Graeme



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Jonas Maebe-2
Graeme Geldenhuys wrote:
> My reasoning for the above. Data loss during string conversions!
>
> 1. The "String" type has too many meanings. I recommend you simply stop
>     using it in your code. Instead, use the exact type you really mean or
>     support in your application.

The same is true in previous FPC versions.

> 2. AnsiString in FPC 3.x is now code page enabled, and can have many
>     different meanings.
>     There is no guarantee that assigning a UTF8String or UnicodeString
>     to a AnsiString is safe.

The same is true in previous FPC versions.

>     On some systems the AnsiString might
>     default to a UTF-8 or UTF-16 encoding which is fine, but importantly,
>     on other systems in might default to something else, and then you
>     simply loose data during the conversion. What makes it even worse,
>     is that the default encoding for AnsiString is determined at
>     runtime,

The same is true in previous FPC versions.

>     so the programmer is completely helpless in preventing
>     this.

Unlike in previous FPC versions, in FPC 3.x the programmer can specify
the encoding that ansistring should use at run time via the
SetMultiByteConversionCodePage().

>     This issue is also not specific to only certain operating
>     systems. You can have a Linux or FreeBSD system that defaults to
>     a non-Unicode type code page, yet the Linux system running right
>     next to that one could have been set up to use a UTF-8 code page.

The same is true with previous FPC versions (since this is obviously
unrelated to the compiler/RTL/language at all, and previous FPC versions
also queried the OS to set the code page used for ansistrings if a
widestring manager was used -- without a widestring manager, nothing
changes either).


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
On 2016-05-09 11:28, Jonas Maebe wrote:
>> >     so the programmer is completely helpless in preventing
>> >     this.
> Unlike in previous FPC versions, in FPC 3.x the programmer can specify
> the encoding that ansistring should use at run time via the
> SetMultiByteConversionCodePage().
>

True, and from earlier mailing list discussions, not many know about
that. No fault of yours of course. The most important point is that by
the time they find out they need to call
SetMultiByteConversionCodePage() they already lost valuable data. All
the compiler does is raise "warnings" in the compiler output, yet
happily compiles further and generates you a fatal executable. Those
should really be errors!

I'm not in the fpc-devel mailing list, but do you mind sharing some
quick information on what the FPC team are planning for the RTL? I
remember years back there was a discussion about two RTL versions
(AnsiString and Unicodestring). Personally I think that would be a
disaster to maintain. In FPC 3.0.0 there seems a hybrid mess (yes I
understand the RTL is not Unicode ready, FPC 3.0.0 only made the
compiler Unicode ready).

My opinion: go the Delphi 2009 route and simply change the RTL to
Unicodestring everywhere (or make a hybrid UTF8String & UnicodeString
versions). If anybody wants the AnsiString or ShortString RTL's, stay
with FPC 2.6.4 and maintain it yourself.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Jonas Maebe-2
Graeme Geldenhuys wrote:

> On 2016-05-09 11:28, Jonas Maebe wrote:
>>>>      so the programmer is completely helpless in preventing
>>>>      this.
>> Unlike in previous FPC versions, in FPC 3.x the programmer can specify
>> the encoding that ansistring should use at run time via the
>> SetMultiByteConversionCodePage().
>>
>
> True, and from earlier mailing list discussions, not many know about
> that. No fault of yours of course. The most important point is that by
> the time they find out they need to call
> SetMultiByteConversionCodePage() they already lost valuable data.

As mentioned in my previous mail, the same happened in previous FPC
versions.

> All
> the compiler does is raise "warnings" in the compiler output, yet
> happily compiles further and generates you a fatal executable. Those
> should really be errors!

You also want errors when assigning longints to bytes etc? (which does
not even produce a warning) The previous compiler version did not even
produce warnings for string conversions that could result in data loss,
and yet you argue that the situation got worse with FPC 3.x.

> I'm not in the fpc-devel mailing list, but do you mind sharing some
> quick information on what the FPC team are planning for the RTL?

There is no such quick information, because it's a very hairy topic and
no agreement has been reached yet.

> My opinion:

Having opinions available is not the issue. Getting people to completely
implement all of their opinions so that we can compare all options in
practice, with the chance that most of those people's work will be
discarded afterwards (or have them implement it in a way that is usable
no matter which option is chosen in the end), is —understandably— much
more difficult.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
On 2016-05-09 11:47, Jonas Maebe wrote:
> Having opinions available is not the issue. Getting people to completely
> implement all of their opinions so that we can compare all options in
> practice,

And we all know that will never happen in FPC. Neither does it happen
[implementing every possible alternative to a problem] in any other
software product or company I've ever come across. So if you think that
is a solution for FPC, I fear you are mistaken.

Again, real-world solution have already been presented to you [the FPC
team]. Java, C# and Delphi 2009+ and many others. Don't tell me they all
got it wrong (with there much larger development teams and resources).
Simply switch the RTL to UnicodeString (UTF-16) everywhere and be done.
Yes you might take a popularity hit for a while with some, but there is
NO way you can please everybody. Somebody will always have an issue. And
like I said, if they don't like the new direction, fork the project and
do your own thing, or stick with FPC 2.6.4 and maintain it yourself.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Tomas Hajny-2
On Mon, May 9, 2016 13:10, Graeme Geldenhuys wrote:
> On 2016-05-09 11:47, Jonas Maebe wrote:


Hello Graeme,

>> Having opinions available is not the issue. Getting people to completely
>> implement all of their opinions so that we can compare all options in
>> practice,
>
> And we all know that will never happen in FPC. Neither does it happen
> [implementing every possible alternative to a problem] in any other
> software product or company I've ever come across. So if you think that
> is a solution for FPC, I fear you are mistaken.
>
> Again, real-world solution have already been presented to you [the FPC
> team]. Java, C# and Delphi 2009+ and many others. Don't tell me they all
> got it wrong (with there much larger development teams and resources).
> Simply switch the RTL to UnicodeString (UTF-16) everywhere and be done.
> Yes you might take a popularity hit for a while with some, but there is
> NO way you can please everybody. Somebody will always have an issue. And
> like I said, if they don't like the new direction, fork the project and
> do your own thing, or stick with FPC 2.6.4 and maintain it yourself.

Regardless from other decisions, we all have already known that new
UnicodeString implementations (or at least checks of full UnicodeString
support without any changes apart from replacing 'string' with
'UnicodeString') are necessary for string handling in the RTL for quite
some time. Nevertheless, not much of that has been created so far.

If such implementations are created, you can always decide if
string/ansistring interfaces should continue to exist somehow (maybe just
performing a conversion and calling the UnicodeString version where
possible), or whether they should become the only ones available.

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
In reply to this post by Jonas Maebe-2
On 2016-05-09 11:47, Jonas Maebe wrote:
> Getting people to completely
> implement all of their opinions so that we can compare all options in
> practice, with the chance that most of those people's work will be


I already have some UnicodeString RTL updates while I worked on the
tiOPF code. I want to submit those to Mantis, but where does RTL unit
tests go (not compiler syntax tests, but RTL)? All my changes have
accompanied unit tests. As far as I understand the <src>/tests/
directory is only for compiler and language syntax tests.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
In reply to this post by Tomas Hajny-2
On 2016-05-09 12:40, Tomas Hajny wrote:
> If such implementations are created, you can always decide if
> string/ansistring interfaces should continue to exist

Exactly what I've done. I've created UnicodeString only versions. I
don't see the point of the others.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Jonas Maebe-2
In reply to this post by Graeme Geldenhuys-6

Graeme Geldenhuys wrote on Mon, 09 May 2016:

> I already have some UnicodeString RTL updates while I worked on the
> tiOPF code. I want to submit those to Mantis, but where does RTL unit
> tests go (not compiler syntax tests, but RTL)? All my changes have
> accompanied unit tests. As far as I understand the <src>/tests/
> directory is only for compiler and language syntax tests.

tests/test/units/unitname


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
On 2016-05-09 13:11, Jonas Maebe wrote:
>
> tests/test/units/unitname

What I've created are FPCUnit based unit tests. Looking a bit further,
what I'm looking for seems to be in tests/test/units/fpcunit/

Thanks again.

Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Jonas Maebe-2

Graeme Geldenhuys wrote on Mon, 09 May 2016:

> On 2016-05-09 13:11, Jonas Maebe wrote:
>>
>> tests/test/units/unitname
>
> What I've created are FPCUnit based unit tests. Looking a bit further,
> what I'm looking for seems to be in tests/test/units/fpcunit/

If these are tests for non-core units (basically nothing that's in the  
RTL directory), that's fine. RTL tests should not depend on FPCUnit,  
because FPCUnit itself may depend on those RTL units functioning  
correctly, which would create a rather annoying catch-22 in case  
something breaks.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
On 2016-05-09 14:16, Jonas Maebe wrote:
> If these are tests for non-core units (basically nothing that's in the  
> RTL directory), that's fine. RTL tests should not depend on FPCUnit,


I unit tested the StrUtils.pp unit. It is part of the RTL, but seems not
to live inside the “rtl” directory, but rather the
“packages/rtl-objpas/” directory. So I presume it is okay to use FPCUnit
then.


Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Michael Schnell
In reply to this post by Graeme Geldenhuys-6
On 05/09/2016 11:57 AM, Graeme Geldenhuys wrote:
> the usage of the aliased "String" type should not be used any more with FPC 3.x.

You can't seriously suggest to dump all code that ever had been written
in Pascal (Delphi Dialect).

-Michael

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Jonas Maebe-2
In reply to this post by Graeme Geldenhuys-6

Graeme Geldenhuys wrote on Mon, 09 May 2016:

> I unit tested the StrUtils.pp unit. It is part of the RTL, but seems not
> to live inside the “rtl” directory, but rather the
> “packages/rtl-objpas/” directory. So I presume it is okay to use FPCUnit
> then.

Yes, that should be fine.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Sven Barth-2
In reply to this post by Graeme Geldenhuys-6

Am 09.05.2016 13:11 schrieb "Graeme Geldenhuys" <[hidden email]>:
>
> On 2016-05-09 11:47, Jonas Maebe wrote:
> > Having opinions available is not the issue. Getting people to completely
> > implement all of their opinions so that we can compare all options in
> > practice,
>
> And we all know that will never happen in FPC. Neither does it happen
> [implementing every possible alternative to a problem] in any other
> software product or company I've ever come across. So if you think that
> is a solution for FPC, I fear you are mistaken.
>
> Again, real-world solution have already been presented to you [the FPC
> team]. Java, C# and Delphi 2009+ and many others. Don't tell me they all
> got it wrong (with there much larger development teams and resources).
> Simply switch the RTL to UnicodeString (UTF-16) everywhere and be done.
> Yes you might take a popularity hit for a while with some, but there is
> NO way you can please everybody. Somebody will always have an issue. And
> like I said, if they don't like the new direction, fork the project and
> do your own thing, or stick with FPC 2.6.4 and maintain it yourself.

In case you missed it we are supporting more targets than Delphi did back when they switched to UTF-16. Unlike C# and Java and Qt we also support MS-DOS and Win16 where memory restrictions are much more likely to arise. We take backwards compatibility rather serious and thus a decision like this where there isn't a technical reason behind it (unlike an upcoming RTTI change) is much less easy to make.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
On 2016-05-09 16:34, Sven Barth wrote:
> MS-DOS and Win16 where memory restrictions are much more likely to arise.

Fair enough. Then use UTF-8 (instead of UTF-16) as the default (or only)
encoding for the RTL. UTF-8 memory usage is on-par with AnsiString (FPC
2.6.4 and earlier) for MS-DOS and Win16 targets - or at least it should
be (the first 255 characters of UTF-8 are single byte encoded).

I fully understand there are a lot of decisions to be made by the Core
FPC Team. But these Unicode and RTL discussions have been going on for
3-5 years now, and still the team is undecided about which direction to
take for the RTL. This doesn't bode a lot of confidence for us or any
company that would like to invest and use Free Pascal exclusively. Bite
the bullet and make a decision - and least then I and other contributors
know where and what to contribute towards. This state of limbo is not good.

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Tomas Hajny-2
On Mon, May 9, 2016 17:49, Graeme Geldenhuys wrote:
> On 2016-05-09 16:34, Sven Barth wrote:
>> MS-DOS and Win16 where memory restrictions are much more likely to
>> arise.
>
> Fair enough. Then use UTF-8 (instead of UTF-16) as the default (or only)
> encoding for the RTL. UTF-8 memory usage is on-par with AnsiString (FPC
> 2.6.4 and earlier) for MS-DOS and Win16 targets - or at least it should
> be (the first 255 characters of UTF-8 are single byte encoded).
 .
 .

No, not quite - your statement does not apply for anything beyond the
first 127 characters (the meaning of all characters starting with #128
depends on the selected codepage and thus encoded differently in UTF-8 in
many cases).

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Mark Morgan Lloyd-5
In reply to this post by Graeme Geldenhuys-6
Graeme Geldenhuys wrote:

> I really think the FPC team should make it blatantly clear that the
> usage of the aliased "String" type should not be used any more with FPC
> 3.x.  It turn I think major alarm bells should start ringing when
> AnsiString type is used too.
>
> Both are fraught with dangers of loosing data.

That's a big claim, and I suggest it could do wit a bit more precision.

What, /exactly/, are you saying can be lost, and under what circumstances?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys-6
On 2016-05-09 17:40, Mark Morgan Lloyd wrote:
> What, /exactly/, are you saying can be lost, and under what circumstances?

You loose “data” due to codepage based AnsiString (aka the String type)
not always supporting all code points of UTF8String or UnicodeString data.

eg:
  I write a program that assigns a UnicodeString value to an AnsiString
  variable. My program uses compiler mode OBJFPC and {$H+}. I run that
  same executable on two different Linux systems.
  NOTE: it's the same executable.

  Linux Box #1:
    The default codepage is UTF-8, thus String equals AnsiString(65001).
    No data is lost when converting from UnicodeString to String on this
    system. Essentially it’s a conversion of UTF-16 to UTF-8 - both
    support the full Unicode range.

 Linux Box #1:
   Here Linux has been setup with a default codepage of ISO-8859-1
   (Latin 1). I have a UnicodeString variable which contains BMP and
   Planes 1-12  code points. The program assigns that to my String
   type variable,  which is actually AnsiString(<latin1>). Only the
   first 255 characters of the 1.4 million Unicode code points will
   be converted. All the others will be replaced by a '?' symbol. A
   massive data loss, and that data could be critical.

What does FPC do about this? It only gives you a compiler warning when
the application was compiled, but still generates the executable as normal.

I now fully understand why Delphi 2009 and later uses UnicodeString as
the default type and their String = UnicodeString = UTF-16. It defaults
to UTF-16 on all its supported platforms (granted, Delphi support a lot
less platforms than FPC does). At least with Delphi it protects the
developers which still uses the String type everywhere (remember String
= UnicodeString there). Much safer than what FPC 3.x does now!


Now some would say, simply switch your compiler mode to DelphiUnicode.
But I don't want to do that, because I like the stricter ObjFPC mode,
and prefer ObjFPC's syntax.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Warning not to use the "String" type with FPC 3.x

Mark Morgan Lloyd-5
Graeme Geldenhuys wrote:
> On 2016-05-09 17:40, Mark Morgan Lloyd wrote:> What, /exactly/, are you saying can be lost, and under what circumstances?
> You loose “data” due to codepage based AnsiString (aka the String type)not always supporting all code points of UTF8String or UnicodeString data.
> eg:  I write a program that assigns a UnicodeString value to an AnsiString  variable. My program uses compiler mode OBJFPC and {$H+}. I run that  same executable on two different Linux systems.  NOTE: it's the same executable.
>   Linux Box #1:    The default codepage is UTF-8, thus String equals AnsiString(65001).    No data is lost when converting from UnicodeString to String on this    system. Essentially it’s a conversion of UTF-16 to UTF-8 - both    support the full Unicode range.
>  Linux Box #1:   Here Linux has been setup with a default codepage of ISO-8859-1   (Latin 1). I have a UnicodeString variable which contains BMP and   Planes 1-12  code points. The program assigns that to my String   type variable,  which is actually AnsiString(<latin1>). Only the   first 255 characters of the 1.4 million Unicode code points will   be converted. All the others will be replaced by a '?' symbol. A   massive data loss, and that data could be critical.
> What does FPC do about this? It only gives you a compiler warning whenthe application was compiled, but still generates the executable as normal.
> I now fully understand why Delphi 2009 and later uses UnicodeString asthe default type and their String = UnicodeString = UTF-16. It defaultsto UTF-16 on all its supported platforms (granted, Delphi support a lotless platforms than FPC does). At least with Delphi it protects thedevelopers which still uses the String type everywhere (remember String= UnicodeString there). Much safer than what FPC 3.x does now!
>
> Now some would say, simply switch your compiler mode to DelphiUnicode.But I don't want to do that, because I like the stricter ObjFPC mode,and prefer ObjFPC's syntax.

So which of these are you complaining about:

a) AnsiString doesn't support codepoints > 0xff ?

b) AnsiString doesn't support codepoints > 0x7f ?

c) AnsiString might apply an inappropriate translation for a codepoint
<= 0x7f ?

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
123