Re: CONST and VALUE revisited

["M. Lazarus" <mlazarus@xxxxxxxx>]

Doug,

 I recall playing a bit and trying to fool the compiler on a CONST 
variable using a DS.  Has someone tried this recently?  I'd like to 
see a working sample that the compiler won't catch.  I think that 
Scott had posted something, but it was a lot more involved than just 
overlaying with a DS.

 VALUE is only really valid when calling a procedure, not a program, 
so it might be more difficult to retrofit older systems.

 -mark

At 1/28/09 03:05 PM, you wrote:
> Jeff,
>
> So, provided my prototype and the PI of the called procedure match, if I
> > specifiy CONST, the compiler will *never* allow the value to be changed in
> > the called procedure?
>
>
> When using a subprocedure (as opposed to external program call via a
> prototype), then the compile will ensure that variable name is not updated.
> But as Alan points out, you can circumvent that by updating the same memory
> location due to DS overlay or whatever.
>
> Also note that with CONST, the original value may or may not be passed by
> reference.  When the original field is the same type/length/etc as the CONST
> parm, the field is passed by reference.  In this case an obfuscated change
> (like a DS) will alter the original field.  However, with CONST if the field
> types are not the same, the a temporary copy will be made and it is passed
> by value.  In this case, even an obfuscated change will not alter the
> original field because only the copy is updated.
>
> Or at least that is my understanding of CONST.
>
> Note that a service program is the same as an internal subprocedure in this
> regard.  It is a prototyped call to an external program (not *SRVPGM) which
> I believe will not enforce the CONST checking.
>
> So while a VALUE will always pass by value (thus safeguarding the original
> from any potential for change), a CONST may or may not be passed by value
> depending on whether the passed field already has the right attributes.
>
> Doug