[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