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

> The returned value is normally a variable that the calling program has
> allocated storage for, either dynamically or at compile time. However,
> if the returned variable is a pointer that has been assigned by the
> called procedure then I would expect that it should point to storage
> that has been allocated as global somehow and therefore always accesible
> by the calling program.

A pointer is just a variable that holds an address.   An address is just a
number, so a pointer is really just a fancy numeric variable.

If you assign it the address of a variable, it's just setting the numeric
variable to an integer.   If you later destroy the source of that integer,
it doesn't matter, the number is still assigned.

The pointer and/or compiler doesn't know that you want global/static
memory assigned to that pointer unless you specifically tell it so.
You do that by specifying STATIC on the variable whose address you're
returning, or by using the ALLOC, %alloc(), malloc() or similar functions
that allocate memory from global areas.

> For instance, if a called service procedure reads from a file that is
> defined only to the service program then returning the address of a
> field in that file seems work.

It will as long as that service program is still in memory.   If you
unload it (end it's activation group, etc) then the contents of the
memory that your pointer is pointing to will be unrpredictable.

> 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.

Exactly.  The result is unpredictable.  What you've done is said to the
operating system "I'm done with this memory, reuse it if you like,
reassign it if you like" and then gone ahead and used it again, anyway.

Sometimes, the OS may decide to use it for another program/routine/etc's
16-byte variable, which is what it sounds like happened to you.   Another
time it may not get used at all, and therefore you get back the result
you assigned to it.   Other times, you may even get an error that you
tried to refer to a space that you're not authorized to.

> 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.

Once again, that's just good luck.   Keep in mind that memory is usually
not blanked/zeroed out when you're done with it or when you get it again.
So, if you release memory, and allocate memory again, there's a good
chance you'll get the same space again.

IF nothing else has happened to write over that space, there's a good
chance that the data will be intact.

But, again, the results are unpredictable.  Maybe next time something will
get that memory first, and your program will crash because of it.
It's simple... don't do stuff like this.   If you must return a pointer
instead of having the caller pre-allocate the memory, then use a STATIC
variable, or a dynamic allocation.

And if you use dynamic allocation, don't forget to DEALLOC it.

> 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?

How can it be?  For speed purposes, the OS doesn't blank out memory.
So, if you happen to get the same area of memory again, it will have the
same values.  Doesn't matter if the activation group is ended or not, it
can still get the same memory by chance.

> Are they stored in the heap or registers that persist despite reclaiming
> the activation group.

Not "registers".   Your pointers are what's remembering the location,
because you're not clearing the address from them when you release the
memory they point to.