Re: LRM 11.6 changing behavior (was: Bug in AdaEd???)

[newsgate.watson.ibm.com!yktnews.watson.ibm.com!ncohen@uunet.uu.net (Norm an H. Cohen)]

In article <CDt6zx.324@crdnns.crd.ge.com>, groleau@e7sa.crd.ge.com (Wes
Groleau x1240 C73-8) writes: 

|> Give me a break!
|>
|>   If I INTENDED to raise an exception, I would normally use a "raise"
|> statement.

Good: That is precisely the programming style presumed by RM 11.6.
(11.6 does NOT allow raise statements to be optimized away, just certain
predefined operations and the checks associated with them.) In the case
of a predefined operation such as array indexing the presumption is that
your algorithm does not count on an exception being raised.  Of course
your algorithm counts on a bad index value not being used, but that's a
different matter.  If an optimizer eliminates the array indexing
operation, it can also eliminate the check that protected against bad
index values.

|> ... it is not reasonable for a compiler to NOT raise
|> the exception.  One of the many purposes of exceptions is to inform programm
ers
|> that they did something they shouldn't have.

In an application demanding high performance, it will not do to check
(for example) that an array indexing operation that is not being
performed (because its results are not needed) WOULD have used a valid
index value if it HAD been performed.

If we were to require Ada compilers to retain otherwise useless
predefined operations just to preserve the possibility of an exception
being raised, we would make it impossible for Ada compilers to perform
the same sorts of optimizations that are routinely performed by C and
FORTRAN compilers.  We would also make it impossible for an Ada compiler
front end to use the same optimizing back end that the front ends for
other languages use.  It is already hard enough to produce Ada compilers
that are competitive in both price and generated-code performance with
compilers for other languages.

There are lots of potential consistency checks (e.g.  assertion checks
for loop invariants, checks that variables have been initialized before
use, checks that deallocated variables are not used, etc.) that could
potentially be performed to assure the programmer or tester that the
program has not entered an unexpected state.  It is not a purpose of the
exception mechanism to ensure that all possible consistency checks are
performed.  A predefined exception is raised in situations where there is
no sensible way to continue normal computation.

If it is a requirement on your program to check that I is within A'Range,
you should code the check explicitly--

   if I not in A'Range then
      raise Self_Check_Failure;
   end if;

--rather than counting on a statement like

   Dummy := A(I);  -- No further use of Dummy

to perform the check implicitly.  (As your note said, if you INTEND to
raise an exception, you should use a raise statement.)

|>                                               Some people are now interpreti
ng
|> LRM 11.6 to mean "If you do write code that the compiler vendor thinks you
|> shouldn't, the compiler vendor has the right to pretend you didn't."

Not quite.  RM 11.6 says that if you write code that the compiler
determines not to affect the state of an exception-free computation, the
compiler has the right to pretend you didn't.  (I'm talking only about
exceptions raised by predefined operations here.)  The compiler is not
required to retain otherwise useless predefined operations just to
preserve the possibility that those operations might raise exceptions.

--
Norman H. Cohen    ncohen@watson.ibm.com