On 13/06/2015 21:48, Jonas Maebe wrote:
On 13/06/15 22:04, Florian Klämpfl wrote:
Or is it documented somewhere that out parameters are finalized first and then
the other parameters
are loaded?
Regardless of whether it's documented, maybe we should do that anyway.
It doesn't seem like a bad idea.
It would in any case not break Delphi Compatibility. And it would remove
one pitfall for dangling pointer vulnerabilities.
A few observations I made. But they are mostly implementation detail, so
if done other ways may be taken...
FPC currently simply decrements the refcount (on calling site). So if
refcount > 1 then the string remains valid. (vaild = not a dangling pointer)
If I am right a ref count of 1 can only happen, if the value is read
directly from memory (variable, via pointer, property without getter)
function bar(a: AnsiString): AnsiString;
begin
result := a;
end;
Foo2(s1,Bar(s1));
in the debugger shows the refcount goes up. So function results may be
safe anyway? If so eval orders of functions does not even need to change.
In Delphi I observed:
- The ref count does not matter. The other param (that has the same
variable) always gets nil
- Except, if resut of a function call
Foo1(Bar(s1),s1);
Foo2(s1,Bar(s1));
Bar always gets the actual value of s1, and then the result of Bar is
passed. (But again that really may be implementation detail)
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
