[fpc-devel] Unnecessary string copy from Utf8String to AnsiString if destination CP is UTF8

[Jonas Maebe]

On 28/04/2019 14:10, Ondrej Pokorny wrote:
> On 28.04.2019 12:35, Jonas Maebe wrote:
>> On 28/04/2019 09:55, Ondrej Pokorny wrote:
>>
>> It's probably what Delphi does as well. The result is that the 
>> refcount of a string after such an assignment is currently always one.
> 
> Thanks for the answer. Yes, Delphi does the same. But strings have 
> copy-on-write so the refcount value doesn't really matter - unless you 
> change the resulting string via a PChar.

Exactly.

> Btw. changing a PAnsiChar/PChar 
> results in a SIGSEGV in FPC but is OK in Delphi. Could you explain this?

http://wiki.freepascal.org/User_Changes_3.0#Literal_storage_memory_has_been_made_read-only

> If changing a string via a PChar is not allowed in FPC than the argument 
> with refcount is not really valid.

It's only for string constants.

> It's funny to see that the holy mantra of the "implementation detail" is 
> used once to support a different behavior and the second time to fight 
> it :)

When a new feature is added, we always try to be compatible with Delphi 
as much as possible, even at the implementation level. The reason is 
that an many Delphi users refuses to accept that there is a difference 
between a language definition and an implementation decision/detail.

Once a feature has been implemented in FPC, we also try to keep it the 
same as much as possible (except when needed to fix bugs), because many 
FPC users are of the same opinion as Delphi users in this regard (and 
even if they accept it, it's still no fun if your code breaks when you 
update the compiler, even if it is your own fault).

>>> See the attached patch.
>>
>> Your patch will return an empty string if orgcp is different from both 
>> cp and CP_NONE.
> 
> This is nonsense.

Sorry, I misread the patch.


Jonas