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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
