[fpc-devel] cpstrrtl/unicode branch merged to trunk

[Hans-Peter Diettrich]

Jonas Maebe schrieb:
> On 07 Sep 2013, at 01:39, Hans-Peter Diettrich wrote:
> 
>> Jonas Maebe schrieb:
>>> On 06 Sep 2013, at 13:54, Hans-Peter Diettrich wrote:
>>>> That conversion IMO is done by the every concatenation, apart
>>>> from subroutine considerations.
>>> I think you mean "afaik" rather than "IMO".
>> I don't talk about concrete code, so I cannot know anything.
> 
> "In my opinion" means "I know the facts, and this is my opinion about
> those facts". "As far as I know" means "to the extent of my (possibly
> limited/incomplete/wrong) knowledge" or, more or less, "I
> think/believe".

Hmm, that turns my understanding upside down.

>>> Anyway, the resulting code page of a concatenation is normally
>>> the code page of whatever you assign the string to (so if you
>>> assign to an utf8string, the resulting code page will be
>>> CP_UTF8).
>> Maybe. I don't know how a concrete compiler handles string
>> concatenations.
> 
> Now you do. It's like that both in FPC and in Delphi.

Sorry, I didn't look at or step through the generated code. I still
doubt that a concatenation function gets an TargetEncoding argument.


>>>> Delphi has overloaded functions for RawByteString and 
>>>> AnsiString(0).
>>> Does this really compile in Delphi?
>> It compiles, of course.
> 
> I think that a "can't decide which overloaded function to call" error
> would be just as logical.

You are right, all calls are ambiguous except test(b).


> Please look at and/or test the FPC code, then present your findings
> about what is actually implemented for FPC.

Later, perhaps, actually I'm busy with other projects.


>>> The DefaultFileSystemCodePage only exists to ensure that a) no
>>> data is lost between you giving a string to an RTL routine and
>>> calling a single byte OS API b) file names returned by single 
>>> byte OS APIs are correctly handled/interpreted by the RTL and get
>>>  their code page set correctly
>> So why do you only specify a codepage, without also declaring an
>> accordingly encoded string type? Such a type would allow for
>> automatic conversion (if ever required) of file/directory name
>> arguments in RTL functions. Which string type would you use for
>> such arguments?
> 
> All of those routines return a "RawByteString". You can assign such a
> string to any ansistring type (including a plain ansistring) and the
> compiler will not insert any kind of code page conversion (and the
> string's code page will also remain the same, even if it is different
> from the declared code page of the string you assigned the value to).

This means that any AnsiString variable can contain any encoding, not 
only the declared one? What's the purpose of specially typed AnsiStrings 
then, and the difference vs. RawByteString?

DoDi