Hi,

Does anyone know what the accepted/excepted behaviour is regarding the capture of addresses of var/out/const-by-address/constref parameters?

For example:

var
  g: longint;
  p: plongint;
procedure test(var l: longint);
begin
  ;
end;
begin
  test(g);
end.

After test() executes, p now contains the address of g (the '@' operator does not return the address of g's address on the stack; it returns the actual address of g). This means that g's address has been captured by test(). This can obviously lead to wrong/dangerous situations, e.g. if g was not a global variable, but a local variable of another procedure. That said, it is a legal expression.

I would like to teach the compiler to be able to assume that addresses of variables are not captured merely because they are passed by reference. There will also be a switch to toggle this assumption, because fortunately it the behaviour is completely defined by the callee side (so if you know that a unit does this, compiling that unit appropriately is sufficient to ensure it will always work correctly).

The question is: should the compiler by default assume that such addresses are not captured, or that they are captured? Does anyone know if a lot of code exists that does this?

Jonas

Your example shows the safe case (p is and will continue to be safe).

In the unsafe case (g to be a local var), this is similar to none "var param"

var
   p: plongint;
procedure test(l: longint);
begin
   ;
end;

p will be a dangling pointer, after "test" exited. The same as in your example, but with the case that "g" is local, p becomes dangling when "g" goes out of scope.

So I am trying to understand what the difference (in terms of safety) is? (except that the none "var param" is always unsafe, the "var param" is only sometimes unsafe)?

Also out of interest, what would change if you ...

teach the compiler to be able to assume that addresses of variables are not captured merely because they are passed by reference

Martin Frb wrote

So I am trying to understand what the difference (in terms of safety) is? (except that the none "var param" is always unsafe, the "var param" is only sometimes unsafe)?

If you are talking about the safety of accesses after the capturing routine has exited, then that is indeed the only difference.

Also out of interest, what would change if you ... > teach the compiler to be able to assume that addresses > of variables are not captured merely because they are passed by > reference

It should allow the compiler to get rid of a lot of temporary function results (and copying those temporary results to their final destination), in particular for shortstring and set operations, and for overloaded operators that work with records.

Jonas

Ok then I am missing some (maybe internal?) detail. Not to important, just curiosity.

Il 10/11/2019 14:36, Jonas Maebe ha scritto:

To me should be simply refused by the compiler as it happens in case of p:=l.
Marco

I've a lot of (interfacing) code where the address of a var is used, where the resulting pointer used locally. I don't think I've code which stores that pointer somewhere outside the procedure.

Marc