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