Re: Passing the same actual as both in and out formal parameters?

[Adam Beneschan <adam@irvine.com>]

On Nov 17, 1:50 am, Ludovic Brenta <ludo...@ludovic-brenta.org> wrote:
> Consider:
>
>    type T is tagged private;
>    procedure P (A : in T; B : out T) is separate;
>    Object : T;
> begin
>    P (A => Object, B => Object);
>
> This seems legal but I suspect the execution might lead to bugs if P
> reads and writes components of A and B in arbitrary order, e.g.
>
> type T is tagged record
>    L, M : Integer;
> end record;
>
> procedure P (A : in T; B : out T) is
> begin
>    B.L := A.M; -- does this change A.L too?
>    B.M := A.L; -- bug: A.L has been clobbered, now B.M = B.L?
> end P;
>
> My concern stems from the fact that T is tagged (I cannot change
> that), so Object is passed by reference as both A and B.
>
> Am I right to be concerned?

As the others have pointed out, the answers to your questions are
"yes", changing B.L does change A.L if the same object is passed as a
parameter to both A and B.  The semantics are well-defined.  My
concern would be whether optimization could change the order of the
operations inside P in a way that affects the results if A and B are
aliases for the same object; I don't know offhand whether this is
allowable for parameters of by-reference types.  I'd have to hunt
through the RM to figure this out, unless someone already knows the
answer.

Whether this (the simpler problem, without optimization) is a concern
or not depends on the situation.  I've written procedures that are
specifically designed to allow the same object to be passed as an IN
and an OUT parameter.  Of course, the body of the procedure has to be
written carefully to allow for this.  There's no way in Ada to enforce
any of this; right now it's just mentioned in the comments in the
package spec ("A and B may be the same object", or "A and B may not be
the same object"), and the caller is expected to obey this, and the
body is expected to perform correctly when they are the same object,
if they are indeed allowed to be the same.

I think AI05-191 is related to this.  Offhand, it appears that if this
AI is addressed, you could put an assertion somewhere (as a
precondition of P, if AI05-145 is addressed) to ensure that P is never
called with aliased (or overlapping) components, if that would be bad.

                                 -- Adam