Re: By value-result vs. by reference

andrewd@apanix.apana.org.au (Andrew Dunstan) writes:
>[Why use value/result? When an Ada procedure exits via an exception,
> the result is not copied back, so you haven't corrupted your actual
> parameter. This makes for rather cleaner semantics in the presence
> of exceptions.]


[Ada from memory -- pardon me if I get the details wrong!]


But -- if anything *is* passed by reference the values *can* be corrupted,
unless (as in Ada) the rule is ``but you can't use it in a way that will
corrupt values before return.'' This rule is tricky for at least two
reasons:


  - The programmer has a lot of rules to remember. Ada says that some
      things will only be passed by value/result but that others may be
      passed either way. This means the rules are complex in the name of
      efficiency, but exceptions can cause control flow that make it hard
      for humans to get it right and hard for compilers to optimize it
      away, so it doesn't buy you much efficiency, and the programmer
      still has a lot of rules to remember.


  - It's hard to promise things about exceptions. The safest thing
      that a programmer can do is to assign only to locals and then copy
      to the reference parameters just before return. But even this can
      blow up if assignment can cause an exception (either when a
      structure is half-modified or if an exception occurs after the
      first assignment has completed). How can assignment cause an
      exception? Consider both structures that span page boundaries and
      field assignment that, as in the VAX, requires floating-point
      values to be valid to be moved.


I haven't played with Ada for a decade, but I recall that at that time the
semantics for structure assignment were that assignment was required to be
atomic -- if an exception was raised in the middle of assignment, the
assignment had to be undone before the exception was raised. In turn,
this meant that user-implemented filed-by-field structure copy was forced
to first copy to a shadow, discarding the shadow in the normal case of
successful assignment.


Here, `assignment' includes return values via reference parameters.
Consider the following code, where `call_by_ref' is assigns to two
parameters, which are passed by reference. In C-like syntax:


global z1, z2;


caller () {
x = y = 0;
z1 = z2 = input();
call_by_ref (&x, &y) : on (ERROR) { assert (x == y); }
}


call_by_ref (&x, &y) {
x = z1;
-- right here, x has new value, y has old value.
-- what if there's now an exception?
y = z2;
}


If, say, reading `z2' causes an exception, then `x' definitely has the new
value while `y' still has the old. The assertion will fail (unless the
old and new values are coincidentally the same). If the call had been by
value/result, the assertion would have succeeded. Thus, `call_by_ref'
really needs to be


call_by_ref (&x, &y) {
shadow = x;
x = z1;
y = z2 : on (ERROR) { x = shadow; raise (ERROR); }
}


Of course if this was a structure that could have been passed by
value/result and if it *was* passed by value/result then you didn't need
to do all the copying and shadow-boxing, but you had to code it like the
above anyway because the next compiler might pass the parameters by
reference.


What this all points to is that details can bog you down in a big hurry,
and that parameter passing conventions really *do* depend on the language
semantics (in a big way).


;-D on ( Floating-point well-taken ) Pardo
--

Return to the comp.compilers page.
Search the comp.compilers archives again.