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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ICNUCEVM.BITNET!MAZZANTI
From: MAZZANTI@ICNUCEVM.BITNET (Franco Mazzanti)
Newsgroups: comp.lang.ada
Subject: Parameter Passing Mechanism
Message-ID: <8902271616.AA11708@ajpo.sei.cmu.edu>
Date: 27 Feb 89 18:15:06 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
X-Unparsable-Date: Mon, 27 Feb 89 17:06 SET
List-Id: <comp.lang.ada>


  --
Subject: Parameter Passing mechanisms
  --
Mats Weber <madmats at elma.epfl.ch> writes:
  --
>There are two points:
>
>  1) This program is not erroueous according to the LRM because its effect
> does
>     not depend on whether V and W are passed by reference or by copy.
>     6.2(13) is a NOTE and according to LRM 1.2(7), notes are not part of the
>     standard. The problem with 6.2(13) is that it is not a consequence of
>     other rules.
>
>  2) 6.2(13) applies here because if V and W are passed by reference, the
>     actual A_Vector is updated by the assignment W(1) := V(1) + W(1); other
>     than by updating the formal V, which makes V(2..5) undefined according
>     to 6.2(13).
>     (See 6.2(7): ... by arranging that every use of the formal parameter
>     be treated as a use of the associated actual parameter...).
>
   --
 I completely agree with your remarks, even if I am strongly in favour of
  position 1).  Notice that the wording in 6.2(13) introduces several
 inconsistencies also with respect to other parts of the standard.
  For example, it states that the use of an undefined array (as a whole) is
  erroneous, in contrast with 3.2.1(18) (stating that the use of an undefined
  scalar variable is erroneous). Moreover it introduces the possibility of
  having undefined access values (still not covered by 3.2.1(18).
  Another interesting example is the following:
   --
    procedure Cancel_6_2_13 is
       --
       type intref is access integer;
       --
       type Rec is record
          ptr1: intref;
          ptr2: intref;
       end Rec
       --
       A_Record:  Rec;    -- components initialized with null
       --
       procedure Null_Effect (Formal : in out Rec) is
       begin
          A_Record.ptr1:= A_Record.ptr1;
          A_Record := Formal;              -- erroneous for 6.2(13)
          if Formal.ptr2 =null then null;  -- erroneous for 6.2(13)
       end Null_Effect;
       --
    begin
        Null_Effect(A_Record);
    end Cancel_6_2_13;
   --
 This kind of issues, however, seems to be already covered by AI-00135, whose
 status is still work-item.
   --
 An even more stimulating issue is whyever a program whose execution depends
 from the parameter passing mechanism should be considered erroneous.
 I perfectly agree that this kind of dependence should be discouraged by
 the reference manual(in the same way as the similar cases of incorrect order
 dependences), however, I do not think that an implementation should be
 allowed to crash when such an error occurs (and this is what allowed when the
 execution is said to be erroneous, and hence unpredictable).
 This more general issue is covered by AI_00588 (whose status is received).
   --
 Does anybody agree?
   --
  Franco Mazzanti                    ARPA: mazzanti at icnucevm.cnuce.cnr.it
  Istituto di Elaborazione dell'Informazione    BITNET: mazzanti at icnucevm
  Via S.Maria 46, I-56100 Pisa Italy,
   -----------
Acknowledge-To: Franco Mazzanti <MAZZANTI@ICNUCEVM>