[fpc-devel] String handling in trunk (was utf8 in 2.6.0)

[Michael Van Canneyt]

On Sat, 5 Jan 2013, Hans-Peter Diettrich wrote:

> Michael Van Canneyt schrieb:
>> 
>> 
>> On Sat, 5 Jan 2013, Jonas Maebe wrote:
>> 
>>> 
>>> On 05 Jan 2013, at 12:53, Paul Ishenin wrote:
>>> 
>>>> ResourceStrings are stored as AnsiString type with 0 codepage (as I 
>>>> remember). Delphi now stores ResourceStrings as UnicodeString type. I 
>>>> think FPC will follow this in m_default_unicodestring modeswitch.
>>> 
>>> It would probably even be better to always do that. At least I don't see a
>>> downside, other than slightly larger binaries (and that's not an issue in
>>> this case as far as I'm concerned; maintaining two separate resourcestring
>>> systems/handlers is just not worth the trouble).
>> 
>> But it means that for
>> 
>> Resourcestring
>>   AString = 'Something';
>> 
>> Var
>>   S : Ansistring;
>> 
>> begin
>>   S:=AString;
>> end.
>> 
>> Always a conversion will happen.
>> 
>> I do not think this is a good idea given that currently, String = 
>> Ansistring.
>
> IMO resource strings are for display purposes, so that UTF-8/16 encoding is 
> expected by an OS API.  AFAIR Win32 string resources are stored in UTF-16,

You are very much wrong.

To start with, resource strings are not stored as Win32 resources. 
Secondly, they are stored in the code as an ansistring.

The resource string of the above example is stored as:

.globl  _$PROGRAM$_Ld2
_$PROGRAM$_Ld2:
         .ascii  "Something\000"
         .balign 8
         .short  0,1
         .long   0
         .quad   -1,15
.globl  _$PROGRAM$_Ld3

Thirdly: in my apps, no UTF-8/16 encoding is expected by the OS. 
If it were, I would have used widestrings instead of ansistring 
to begin with, and in that case I would not have made any remark...

So the conversion really would be 100% totally redundant.

Michael.