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
ONLY
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.
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
