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

[Rory Hewitt <rory.hewitt@xxxxxxxxx>]

Larry,

I was under the (it appears mistaken) impression that if I receive a
parameter which was passed to me as *OMIT (and therefore the address of that
parameter is null) that it would/could fail when I pass it to another
parameter, even if that procedure allows the parameter to be omitted.

If that wouldn't cause a runtime error, then yes, the process is much
simpler (assuming you use %parms in all procedures to check for unpassed
parameters, obviously).

Rory

On Fri, Mar 11, 2011 at 4:44 PM, Larry Ducie <larry_ducie@xxxxxxxxxxx>wrote:

> Hey Rory,
> <snip>
> 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?
> </snip>
>
> Passing a null (or invalid) address of an incoming parameter to another
> procedure is the main cause of issues when using OPTIONS(*NOPASS) in chains
> of procedure calls, and is core to the OPs original problem. It is way too
> easy to pass a reference to a parm you didn't actually receive to another
> procedure. That is why we have to check %parms and use the appropriate call
> - ensuring we don't pass what we didn't receive.
> This is not the same for OPTIONS(*OMIT). We did receive a valid (null)
> address. This null address can be safely passed on only if the procedure you
> are passing the ommitted parameter to also has OPTIONS(*OMIT) defined for
> that parameter. If it does the called procedure would have code checking the
> validity of the parameter.
>
> <snip>
> 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).
> </snip>
>
> Using an incoming parameter on a call does not check the validity of the
> parameter address. It is just passed I believe. There will be scenarios
> where a conversion due to the use of const or value fails, but that is
> another issue.
>
> <snip>
> 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...
> </snip>
>
> I understand your concerns, but this would only be an issue if the
> procedure you are calling is not expecting an omitted parm. In this scenario
> you are correct. In the case of the OPs example both procedures had the same
> definition for parms 2 and 3. So, if proc1 accepts a *OMIT in parm 2 it is
> reasonable to pass that *OMIT along to parm 2 of proc2. Passing an invalid
> (or even sometimes accidentally valid) address for an non-passed parm 3 to
> proc2 is, however, totally unacceptable. This is why we check %parms and
> only pass parm 3 if %parms >= 3.
>
> Cheers
>
> Larry Ducie
>
>
>
> --
> This is the RPG programming on the IBM i / System i (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.