From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!nosc!cod!sampson From: sampson@cod.NOSC.MIL (Charles H. Sampson) Newsgroups: comp.lang.ada Subject: Re: aliases/function return values Message-ID: <2088@cod.NOSC.MIL> Date: 31 Aug 90 00:47:32 GMT References: <12594@encore.Encore.COM> Reply-To: sampson@cod.nosc.mil.UUCP (Charles H. Sampson) Organization: Computer Sciences Corporation List-Id: 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