Re: GNAT 4.4.5 order of conditional processing?

[Adam Beneschan <adam@irvine.com>]

On Nov 16, 1:31 pm, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> On 15 nov, 22:49, awdorrin <awdor...@gmail.com> wrote:
>
> > Figured that was is, sloppy programming that just managed to work (for
> > 20 years) due to a compiler implementation... ;-)
>
> Waw, so there was an Ada compiler doing (erroneously of course) a
> silent short-circuit ?...

Not necessarily... Later on, the poster said that the issue was with
uninitialized variables.  In an expression like this:

  if Expression-1 and Expression-2 then...

where Expression-1=FALSE means that some variables in Expression-2 are
uninitialized.  The fact is, though, that even if Expression-2
involves variables that contain unpredictable garbage, using them is
unlikely to cause any harm in most situations.  For instance:

  subtype Index_Subtype is Integer range 1 .. 10;
  Arr : array (Index_Subtype) of Float;
  Curr_Index : Index_Subtype;

  if Curr_Index_Initialized and Arr(Curr_Index) < -1.0 then ...

Suppose Curr_Index_Initialized is FALSE and Curr_Index has never been
initialized to anything.  The result is that if the right side is
evaluated, Curr_Index's uninitialized value may be a value outside the
range 1..10, and then the code will read an element of Arr that is
outside the bounds of Arr.  Big deal.  That's not likely to make a
program fail.  (Unless the bit pattern it reads happens to be a
Signaling NaN, maybe!!)

But I also want to point out that a "silent short-circuit" is NOT
necessarily erroneous.  In fact, it's probably not erroneous in most
cases.  The compiler doesn't have to evaluate both operands of "X and
Y" if X is false and evaluating Y cannot have any effect on anything.
Also, if the only possible effect of evaluating Y is to fail a
language check, then I think Y doesn't have to be evaluated by 11.6.
Thus, if you write:

  if (N in My_Array'Range) and (My_Array(N) = 0) then ...

If N is out of range, the language says this should raise
Constraint_Error when My_Array(N) is evaluated.  So that means that
the above code shouldn't be written like that.  But a compiler that
generates code that doesn't raise Constraint_Error is, I think, legal
by 11.6.  So a compiler that generates the exact same code for the
above example and for

  if (N in My_Array'Range) and then (My_Array(N) = 0) then ...

is OK.  Obviously, programmers shouldn't count on it.  (And there may
be some differences of opinion as to how 11.6 is to be interpreted.
It's caused arguments in the past.)

I believe the only time the compiler *must* generate code that always
evaluates both operands is if the right-hand side contains a function
call that could have a side-effect, or if it refers to an object where
reading the object could have some external effect (i.e. a memory-
mapped device address or the like).

So there's a couple of reasons why (in a correct implementation) using
"and" instead of "and then" could be erroneous but still not cause the
program to fail.

                             -- Adam