Re: Bug in AdaEd???

[eachus@mitre-bedford.arpa (Robert I. Eachus)]

In article <9309221412.AA02787@ieipisa.iei.pi.cnr.it> mazzanti@iei.pi.cnr.it (F
ranco Mazzanti) writes:

  > Paragraph 11.6(7) deals with predefined operators, but the assignment, or
  > the check to be performed before an assignment are not predefined operators
  > but "basic" operations (see Ref. Man 3.3.1).

    There is a subtle distinction in Ada 83 between predefined
operators and predefined operations.  Predefined operations include
the basic operations, enumeration literals, and the predefined
operators. See 3.3.3 (2) where unfortunately it uses the phrase "the
remaining operations."  (You might also want to look at 8.6(1), or at
the Ada 9X RM 3.2.3, where predefined operation does appear in
italics.)

     But, in any case, in the context of 11.6, if you look at
paragraph 3, you will see the phrase "predefined operations that are
either predefined operators or basic operations other than
assignments."  At first glance this looks like a definition of
predefined operations, but it is really excluding assignments from the
scope of the optimizations in paragraphs 4 and 5.  In other words,
that exclusion is there to prevent reordering of assignments.  But
assignments were intentionally included in the scope of 11.7,
specifically to allow elimination of assignments to dead variables.

     This is why there is no easy fix to the problem.  (Ada 9X has
some fixes, but we still need a new 11.6.)  There is no intent or
desire to require that assignments to dead variables be made, and
therefore any exceptions inherent in the assignment may not occur.
What is needed is a way for a programmer to say "trust me here, you
must make this check."  In Ada 9X it will be definitely be possible to
do this in a portable manner.  Current thinking has gotten as far as
either a pragma OR a local (or maybe statically enclosing) handler for
CONSTRAINT_ERROR will indicate that statements (assignments?) which
potentially raise CONSTRAINT_ERROR should not be optimized away.

     Compiler writers would also like the freedom to make more
optimizations and users would like their programs to run faster.  Of
course no one wants any changes which make existing code incompatible.
All in all a nasty can of worms.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...