Re: Calling similiar (overloaded) procedure that has *nopass *omit in the parameter

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

This is true, but the consequences of accessing an *OMIT parameter 
that's set to *OMIT are well-known, and 100% predictable.

However, the consequences of accessing a *NOPASS parameter that hasn't 
been passed are not predictable. It might give you an error, it might 
not.  It might change unused memory, it might not.  It might change 
actual used memory, or it might not. It's unpredictable.

With *OMIT, testing your code properly is sufficient to know that it was 
written properly. With *NOPASS it's not -- you could have success during 
testing, but have it screw up the program in unpredictable ways during 
production.

So *NOPASS requires you to be an "expert" of sorts. (Very much like 
*VARSIZE).  You need to be able to determine via your own knowledge of 
the environment whether your code is safe, and not via testing.

I find myself agreeing with others on this list when they say IBM should 
do something about it.  But, what, exactly?  Should the procedure make 
it's own copy of the parameter area, use the prototype to null out any 
areas that weren't passed in it's own copy?  Or should all ILE languages 
be extended to know how many optional parameters there are, and fill the 
optional parms with nulls?  (That'd be very hard to do, since languages 
like C and Cobol would have to be changed significantly, and they're 
both following ANSI standards.)

Solving it within RPG might be better, but would be more costly for 
performance.  (Copying all parameters to a new space in memory on every 
call.)

Oh well.


On 3/11/2011 10:21 AM, Rory Hewitt wrote:
> Larry,
>
> If a procedure has a parameter passed to it as *OMIT, then the address of
> that parameter is null. If this parameter is referenced (including simply
> passing it to another procedure), could that cause runtime problems?
>
> I assumed (there I go again, making an ass...) that using that parameter
> directly could give the same sort of problems as referencing an unpassed
> parameter (even though they are very different things).
>
> Essentially, all parameters are based variables and an omitted parameter is
> simply one where the basing pointer is null. Thus my concern over passing an
> omitted parameter to another procedure...
>
> Rory