Alan,
<snip>
I really wish the compiler would implement a CONST_AND_I_MEAN_IT option
i.e. the parm is always passed by copy.
</snip><<
I am confused. I thought that was exactly what VALUE meant.
CONST does not mean I guarantee this value will not be changed. Just that I
will try.
So are you thinking about it in the context of Program to Program calls?
I've never seen a *PGM API use Pass-by-value, (i.e., the VALUE keyword) and I
wouldn't even have considered it to be a possibility. But I suppose it may work.
CONST parms can't be changed by the called subprocedure, unless as Joe explained
there is some subversion going on. But even then, if I recall correctly, there
is in fact a runtime error that will occur if you pull the address-of the const
and try to modify it. OS/400 pointers are very secure.
The stack thing is all academic--it doesn't really occur that way on real
computers like System i. Sure its simulated but at the end of the day, just a
pointer is passed by reference, not the value. Sure some things are put into
registers, but even VALUE parameters are passed by reference under the covers.
(Correctly if I'm wrong about this; if I am, I'm sure someone will.)
The compiler just makes a copy of a pass-by-value parameter value into a work
field that the compiler generates. That field is then passed by reference to the
called subprocedure so that it can be modified without impacting the original
variable's data. Upon return the by-VALUE work field is discarded.
So, having said this, I suppose VALUE could work on program-to-program
calls--but again, I have no need or desire to verify that.
-Bob
midrange.com
