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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8e64f4db20d57eb5 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Call by reference vs. call by value Date: 1996/07/23 Message-ID: #1/1 X-Deja-AN: 169812757 references: <31F10E50.726@egr.uri.edu> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-23T00:00:00+00:00 List-Id: Peter Amey said "This is another Ada feature well covered by the SPARK subset. The rules of SPARK (which are checked by the SPARK Examiner) prohibit all cases of aliasing where program meaning might be affected by the parameter passing mechanism used. A SPARK program has copy-in, copy-out semantics regardless of the compiler used to compile it." Right (or for that matter you can say a SPARK program has by reference semantics regardless of the compiler used to compile it [for the array case] :-) SPARK itself is too restrictive for a lot of general use purposes, but the kinds of restrictions that it has are worth considering individually in any coding standard. 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 the above (Fortran) rule is he one you should have in mind wihile programming (it is a bit more restrictive than the Ada 95 approach, since there are progrmas whose effect does not depend on the mechanism, but which violate this rule), but in practice it is perfectly workable. 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).