Re: Returning a pointer (was - parameters - const, value, reference)

Peter Connell wrote:
> 
> ... But exactly what happens if you return the address of a variable that is 
> local to the called procedure since I would expect that these exist in 
> automatic storage and therefore the data at the address pointed to after 
> returning is unpredictable. Debug shows the first 16 bytes at that address 
> are destroyed.

Indeed that data is unpredictable - returning the address of automatic
storage should never be done.  It may seem like nothing should happen
between the RETURN statement and the assignment of the return value in
the caller.  But actually, some stuff has to happen - at the very least,
the called procedure has to be taken off the invocation stack.  That
automatic storage probably gets reused a few times before the
assignment.

> 
> Another related question. Once the called procedure has been entered, where 
> are the passed parameters stored? Are they stored in the heap? The reason I 
> ask is that I have a situation where a procedure in a service program has a 
> parameter specified as *nopass. It seems that if the parameter is passed on 
> the first call but not on the second call then the second call still appears 
> to be able to access the parameter whose value remains from the first call. 
> The really strange thing is that this is still the case even when I reclaim 
> the activation group in which the service program runs before the second 
> call. How can this be? Are they stored in the heap or registers that persist 
> despite reclaiming the activation group.

I don't know where the parameters are stored.  I think there might be a
separate heap for parameters.  Never never never refer to an unpassed
(*nopass) parameter.  (For *omit parameters, it's ok to use %addr to see
if they were passed.)