Re: Ada and Automotive Industry

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <mazzanti-1112961142160001@131.114.200.115> mazzanti@iei.pi.cnr.it (Franco Mazzanti) writes:

  > AI-00828 and AI-00587 (just to mention two) are not catalogued as "study" 
  > issues but as "ramifications".  The underlying uncertainty, however,
  > has not been removed in Ada95 (A note in the ARM would have
  > probably been sufficient).

   Ramification has a very specific meaning in the case of AI's.  It
means that the answer can be derived from the reference manual, but,
in the case of published AIs, that the ARG felt that it was worth
explaining.  So an AI decided as a ramification is in the same
category as a confirmation but with a different feel:

   Confirmation: "Of course that is what reference manual says, and we
aren't going to change it no matter how silly you think it is."

   Ramification:  "It may seem that this point is not described in the
reference manual, but if you spend a few months looking, you will find
that..."

   To take the first of the two mentioned AIs, AI-828 "File objects
need not be passed by reference" is a very good example of a
ramification.  The "obvious" implementation of FILE_TYPE in the IO
packages is as a pointer to a file descriptor.  But in Ada 83 this
implementation is not required, and there are programs which can
detect the difference.  Oh, and other changes in Ada 95 make some of
those implementations, and some of those programs illegal.  However,
it is still legal to make a file object an index into a table of file
descriptors, and pass it by value.  (And yes this topic was discussed
during the langauge revision.)

   The second probably should have been classified as presentation,
and that is how it was resolved in Ada 95.  (Well, part of the fix
involves the fix for AI-315 in section 11.6.)  All issues of
erroneousness like this were moved to a new section 13.9.1.  In the
process, some of the programs that were erroneous in Ada 83 were made
non-erroneous.  In this particular case (an assignment to a
subcomponent of an object with discriminants, where the discriminants
are changed as a side-effect), it is only if the subcomponent is
subsequently referenced that makes the program erroneous.  Notice that
this is an extremely difficult case to imagine (or construct).  You
have to have an object with discriminants containing a sub-component
depending on the discriminants, and an assignment where the required
order of evaluation breaks things.  You can write--the usual way is an
index value with side-effects--but it is the sort of code that gets
you killed even if it does "work."

   So I assume the ramfication classification was homage to the amount
of work needed to actually construct a case where the rule applied.
(Or possibly allowing for the fact that when in the course of doing
the assignment the program became erroneous could affect things. ;-)



   
--

					Robert I. Eachus

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