[fpc-devel] new string - question on usage

[Luiz Americo Pereira Camara]

On 10/10/2011 14:12, Martin wrote:
> With fpc trunk strings are now codepage aware.
>
> I currently face the issue, that lot's of old code just use "var foo: 
> string". or sometimes explicit "ansistring". No idea what encoding 
> that stores, put it does not seem to be utf8.
>
> If I pass such a string (which contains utf8, but seems not to be 
> marked as such) to a function declared as
>   function Bar(val: Utf8String): Utf8String;
> then I can see that it gets converted (which of course renders the 
> data completely broken).
>
> Now until I can convert all the strings to Utf8String, and until I can 
> test all of that.... I need some work around for the very few places 
> where such a call happens.
>
> Is there a way to pass the string as argument but to suppress 
> conversion (but keep the function declaration as it is with utf8string)?

AFAIK the fpc feature is incomplete and buggy so it will not work anyway 
and making workarounds to it now is a bad decision. Changes in Lazarus 
must be done after the dust settle in fpc side.

When this time comes, this is what i see:

1- Most of LCL must be code page agnostic, so not use 
UTF8String/AnsiString directly (keep String)
2- It should have (dont know if currently has) a compiler switch to 
change the default code page to UTF8 or whatever, so all variables with 
type String will map to UTF8String.
3- The UTF8String/AnsiString type should be reserved where strictly 
necessary like libraries that require UTF8 or RTL interfacing

The bug that you cited wont happen if you use the feature of point 2. 
But this wont work properly anyway since the unicode RTL/classes is not 
done yet.

Luiz