Ah, ok, thanks.
that may work.
Is it documented somewhere, under which circumstances uniquestring is
inserted by hte compiler, and when not? In other words, is there a way
to be sure, that it will not be called twice in future versions?
(Not that it would be a big issue, if it was called twice, but always
eager to learn.)
The background for this question is motivated by:
http://bugs.freepascal.org/view.php?id=11280
Many of the occurrances look like
SetLength(s, count);
move(str^, s[1], count);
where "s" is a local variable, not used before. So currently it would be
safe to skip uniquestring.
But I consider this as a trap, because future changes may act on "s"
before, without the author being aware of the exact behaviour of move.
Since the issue is widespread throughout the code (the bug only shows a
few samples), and the current access "s[1]" does work, except for the
(falsely) triggered rang-check, I find it a bit over the top to prefix
every line with "if length(s)>0"
---------------
I also see that (s: AnsiString)
move(str^, s, count);
seems to work too. (again without implicit uniquestring)
Is there anything against this syntax?
It does not convert s to nil, in case of empty string, but since len is
0 nothing will happen.
Thanks a lot
Martin
Jonas Maebe wrote:
On 13 May 2008, at 00:17, Martin Friebe wrote:
move(somepchar^,pchar(ansi_str_dest)^,len);
doesn't check fpc_ansistr_unique. So it works only if ansi_str_dest
has only one reference; or both strings will be modified (because no
copy-on-write happens).
At least, that's what I get to see, if I compile with -al and look at
the assembler.
You can call uniquestring(ansi_str_dest) before the move()
Jonas
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
