Re: Call by reference vs. call by value

[bobduff@world.std.com (Robert A Duff)]

In article <dewar.838132574@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>I actually like the Fortran rule as to exactly what is and what is not
>allowed in Fortran. It is as follows:
>
>  if there are two aliased paths to the same object, it is erroneous (to use
>  the Ada terminology) to assign to the object via either path.
>
>That's a very well defined rule. I much prefer it to eithe the bogus rule
>in the Ada 83 RM (erroneous if effect differs, but effect never defined),
>or to the Ada 95 RM rule that programs are simply non-determinisitc if
>their effects depend on the mechanism.

I think both the Ada rule and the Fortran rule are pretty ugly.  The
problem is that you can't pin the error down to one piece of code.  Is
it the fault of the caller, or the callee?  There's nothing in the spec
that gives any sort of contractual information about which side has to
do what.

>You can now if you like follow this up with specific coding rules designed
>to prevent this from occurring (e.g. forbidding globally visible objects
>to be passed as out or in out parameters to routines that can see the
>global, or forbidding the same object from being passed as two separate
>parameters if one of them is out or in out).

But at the call site, I can't tell which global variables are visible to
the callee, without looking at its body.  So not only can I get bugs,
but the bugs can be triggered by porting the code, or by turning on the
optimizer, which is more painful than a normal run-of-the-mill bug.

I must admit it's not *that* big of a deal, since you don't normally
have a lot of global variables lying around.

- Bob