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

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Jean-Pierre Rosen wrote:
> Ludovic Brenta a écrit :
>> My exampled was heavily simplified; the actual type has about a
>> hundred components and the procedure P is a little more complex than
>> swapping components :)
>
> > But thanks for the responses, Niklas and Jean-Pierre. They confirm my
> > suspicion.
>
> But the important thing is that there is no risk: behaviour is well
> defined, and will not change with the next release of the compiler.
>
> If it is not the behaviour you want, you can make a local copy (but you
> know that).

Indeed; I was careful not to use the phrases "bounded error" or
"erroneous execution", just "bug" :) The construct is well-defined but
error-prone and needs documentation in my sources, so I've added that.
Triggering the bug requires:

(1) pass-by-reference type (i.e. tagged, limited, etc.) or explicit
access type
(2) same object passed twice as both in and out parameters
(3) non-atomic reads and writes to the object inside the subprogram

When writing such a procedure, it is necessary to pay attention:
either prevent the bug by checking for condition (2) and raising an
exception if it is met; use only atomic operations so as to prevent
(3); or accept that the bug may happen and warn about it.

In my particular case, the operations are "atomic" in that the
procedure first reads the Object, then passes it as an "out" parameter
to another procedure, and never reads it again. However, this being
long-term-support software, one never knows that (3) can never happen
in some future revision.

--
Ludovic Brenta.