RE: passing along *NoPass arguments

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

-----Original Message-----
From: rpg400-l-bounces@midrange.com
[mailto:rpg400-l-bounces@midrange.com]On Behalf Of Jon Paris
Sent: Wednesday, January 08, 2003 7:27 PM

>The compiler does not defend against passing unpassed parms - just as it
>doesn't stop you from attempting to reference those fields.  Unlike called
>programs, attempting to reference an unpassed parm on a bound call will not
>necessarily blow up - sadly.  If there is a valid pointer on the stack it
>will use it and you'll be passing goodness knows what data.

>Seems to me that it would be a nice compiler option to be able to specify
>that any attempt to reference an unpassed parm would result in a null
>pointer being used.  That would have given you the result you expected.
For
>compatibility reasons we're stuck with the current behavior as the default
>and I know it would be less efficient, but the current situation is just
>plain dangerous.


I would add that passing a parm variable that was not passed (follow <g>)
should be allowed if the parm in the proc being called is declared as
options(*NoPass).  Hopefully a *NoPass parm variable has something like an
associated attribute byte that contains the pass/nopass status of the
variable.  If so, then passing it along to a downstream proc is simply a
matter of passing either the attr byte or the variable depending on the attr
byte setting.

A %passed bif would also be useful.
  if  %passed(InParm1)  ;    // test if the parm was passed.
  endif ;

Steve Richter