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

Barbara,
May I take this opportunity to quiz you?
Although this is not the same issue from which this thread arose, it does 
relate to calling conventions, specifically return values.

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

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.

Peter
  
----Original Message-----
From: Barbara Morris [mailto:bmorris@xxxxxxxxxx]
Sent: Tuesday, June 24, 2003 7:33 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: parameters - const, value, reference


Richard B Baird wrote:
> ...
> 
> if you have a rather large string that you might want to change locally,
> does it matter whether you pass by value and change in-line, or
> const/reference and move it to a locally defined variable for manipulation
> - 6 of one, .5doz of another. you are still moving the data.
> ...

Passing large parameters by value isn't something that the iSeries is
optimized for.  (I think this probably applies to any system.)

If you have procedures dealing with strings, defining the parameters as
CONST VARYING will probably get you the best performance.  If your
procedure has to make a local copy, it will only have to copy the
current length.

_______________________________________________
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