Re: Procedure PR/PI question

I think the point 'what sson' was trying to make, was that passing a global variable as a CONST parameter to a local subprocedure can get you in trouble, as the procedure changes the global variable. Now we may all agree that using global variables is evil, but up to V5R4 (just a few months, just a few months, ...) files had to be global. That means that all programs written before 6.1 that use files (that might be quite a few) have a lot of global variables.

If you use an input field as a CONST parameter to a local procedure and that procedure (or another local procedure that is called by this procedure) reads another record in the same file, your CONST parameter suddenly changed. So I can understand what sson's feelings about using VALUE for local procedures.

Joep Beckeringh


Op 30 apr. 2013, om 01:08 heeft Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> het volgende geschreven:

On 4/29/2013 1:54 PM, Alan Campin wrote:

As I have said many times, VALUE means the compiler says I guarantee that
variable in the calling program will not be changed and it does that by
making a copy and pass a pointer to it.

Passing by VALUE does not involve passing a pointer to it. It simply
copies the data from the caller's variable to another variable that's
local to the procedure. It does not pass a pointer.

By contrast, CONST, if the variable size/type does not match does
exactly what you're attributing to VALUE -- it makes a copy and then
passes a pointer.

CONST means I will try to keep you from changing it but there are plenty of
ways to change the variable inside the procedure and have the calling
variable to be changed. These include passing as a parameter to a program
inside the procedure, getting a pointer to it, putting in a data structure.
The compiler may try to prevent you from changing but it is easy enough to
change which could result in some really nasty bugs.

Complaining that CONST is bad because a variable can still by changed
though another non-CONST interface is like complaining that the locks on
the front door of your house is bad because burglars can still steal
your TV by entering through the back door.

The fault isn't with CONST, it's with the fact that you have two
different methods to access the same variable.

Or, that you are lying to the compiler... using a prototype that doesn't
match it's corresponding procedure interface.

That is why I always use a VALUE unless I passing something really big and
lately I have using Option(*String) to pass long variable strings.

VALUE is okay for short things, such as numeric values, but some
environments (SQL comes to mind) don't allow VALUE. Then you end up
with wrappers, et al.

Really, it's nearly impossible to "accidentally" change a CONST
parameter. You pretty much have to be trying to do so. Don't throw
away the baby with the bath water!
--