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

Barbara,
Thankyou, you have answered precisely the questions about which I was wondering 
(without being presumptuous I might add).
Your answer confirms just what I suspected which now permits me to offer more 
confident guidance to those of our developers who tend to stray into use of 
such unwise practices.

You may be a little surprised (but then again not) that one of the unwise 
practices here is that someone discovered that they could avoid unreferenced 
pointer exceptions to unpassed parameters by actually coding a PLIST within the 
called procedure that redeclares the parameters declared in the procedure 
interface (get that). The danger is compounded by the fact that all procedures 
here use the *CALLER activation group which would explain why the parameter 
retains it's value until the default activation group is destroyed by ending 
the job.

Peter     
 
-----Original Message-----
From: Barbara Morris [mailto:bmorris@xxxxxxxxxx]
Sent: Thursday, June 26, 2003 1:33 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: 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.)

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

This correspondence is for the named person's use only.  It may contain 
confidential or legally privileged information, or both. No confidentiality or 
privilege is waived or lost by any mistransmission. If you receive this 
correspondence in error, please immediately delete it from your system and 
notify the sender. You must not disclose, copy or rely on any part of this 
correspondence if you are not the intended recipient. Any views expressed in 
this message are those of the individual sender, except where the sender 
expressly, and with authority, states them to be the views of Baycorp 
Advantage.If you need assistance, please contact Baycorp Advantage on either :- 
        Australia 133124 or New Zealand +64 9 356 5800