Re: aliases/function return values

[sampson@cod.NOSC.MIL (Charles H. Sampson)]

In article <12594@encore.Encore.COM> jcallen@encore.com (Jerry Callen) writes:
>I've run across a curious anomaly with the value returned by a function;
>if the function value is returned by reference, an alias can be created.
>
> [Example showing one of the usual aliasing problems deleted.]
>
>          ... Is a compiler permitted to return objects "by reference"
>(with the possibility of creating aliases) or must it create a copy
>of the return value? I can't find anything in the LRM on this point,
>although there is some gobble-de-gook in 6.2.13 that might be relevent.

     I don't remember this problem being explicitly covered in the LRM,
I can't think of any place to look, the ARG appears never to have dis-
cussed it, and 6.2(13) doesn't apply because the subject there is sub-
program parameters and a function's value is not one of its parameters.

     However, there's no need for an explicit statement in the LRM.  The
implementation is wrong because it violates the semantics of a function
invocation.  Each invocation of a function determines an associated value
and that value cannot mysteriously change after the invocation has com-
pleted.

     Another respondent has said this might be a useful compiler error,
presumably on the basis of efficiency of the implementation.  I don't
want my function values to change after they've been calculated, no
matter how efficient the code is.  It should just be accepted that func-
tions that return large structures are not going to do so with the same
kind of code as a Boolean-value function, but this "inefficiency" might
well be offset by other considerations, for example the avoidance of un-
pleasant side-effects.

(Does anybody else remember the quote from The Psychology of Computer
Programming: "If you're not interested in correct answers, I can write
a very fast program for you.", or words to that effect?)

                            Charlie Sampson