MAZZANTI@ICNUCEVM.BITNET (Franco Mazzanti) (02/28/89)
-- 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>