[fpc-devel] move(xx, ansistring[1] versus ansistring, len)

[Martin Friebe]

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  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel