[fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?

Jonas Maebe jonas.maebe at elis.ugent.be
Mon May 13 14:08:25 CEST 2013

On 10 May 2013, at 03:19, Bruce Tulloch wrote:

>> The compiler turns such functions into procedures with an implicit
>> var-parameter
>> and the *caller* passes the location where the function result  
>> should go
>> via that
>> parameter.
> Okay, thanks, that clarifies, now I understand how a variable in the
> caller's scope can be affected while making assignments to Result in  
> the
> callee's scope BEFORE callee has finished executing.
> Another way of stating this is; Result is a local variable of a  
> function,
> initialized to nil and passed by value to the caller upon completion  
> if Result not a reference to a dynamic type, otherwise it's an  
> implicit var
> argument with scope beyond that of the function.
> Is that correct?

Yes, apart from the fact that result is never initialized to nil.

> If so, it would seem to be a bit of semantic trap for the
> unwary :-)

Differences in the execution because of the above change can only  
occur in case you have memory corruption. On the other hand, in that  
case anything is possible regardless of what optimisation have or have  
not been performed by the compiler.

>> Such optimizations only occur in safe situations (e.g., not when
>> assigning to a
>> global variable...
> Does the compiler consider ANY non-local variable to be global?
> For example, fields of an object?

These are indeed global. And so are e.g. local variables whose address  
has been taken, that are used in assembler code, or that have been  
passed to a var-parameter (because the called routine may then have  
stored its address). There are no cases that I know of where the  
compiler can perform that optimisation in an unsafe scenario.


More information about the fpc-pascal mailing list