[fpc-devel] ref count issue with out param
Martin Frb
lazarus at mfriebe.de
Sat Jun 13 23:42:38 CEST 2015
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)
More information about the fpc-devel
mailing list