Re: Ada and Automotive Industry

[mazzanti@iei.pi.cnr.it (Franco Mazzanti)]

Robert I.Eachus said:

> 
>    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..."
> 

I Agree, that "ramification" AI's are not as important as
"binding interpretations".  However:

A)  They would deserve at least a note in the ARM. At least to avoid the
    representation of the same question for Ada95.

B)  When they are associated with a status of "received", it is not clear
    how meaningful the classification is. If no discussion has ever been
    held on the subject, it is still possibile that the provisional 
    "ramification" classification is not the correct one.

>    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 language revision.)

I believe that this topic was discussed, but unfortunately the 
underlying problem has not been resolved. A typical FILE_TYPE 
implementation is a pointer to a file descriptor <which is created when 
a file is opened and is set to null when a file is closed>. When such 
pointer (or index) is passed as a parameter, it continues to reference a
file descriptor which might no longer exist if the file object is, in 
the meanwhile, closed.
The resulting behavior is very likely to be inconsistent.  The real
point behind  AI-828 is not the academic question on whether or not it 
is allowed to pass FILE_TYPE by copy, but what is supposed to be the
semantics when this happens.
Ada95 doesn't provide the answer and the issue is still uncertain.
This issue should not be classified as a "ramification" but as a binding
interpretation (once a solution is found). My impression, is that nobody
wants to explicitly state that using a parameter of type FILE_TYPE is
erroneous if the file-object status has been changed, nor wants to force
implementations to behave in a different way. 

> 
>    The second probably should have been classified as presentation,
> and that is how it was resolved in Ada 95.  

With respect to AI-00587 (which I have the impression you have confused 
with AI-00585) I agree that this item could have been classified as
"presentation".
However the original wordings of Ada83 have been reused in an equally
wrong way in Ada95 (precisely in 3.7.2(4)). Here the issue are the words
"by this execution" (which does not include the activity performed by 
other independent, but synchronized tasks). 
I am the first to acknowledge that this is a very minor, presentation 
point, but it would have been easy to take it into consideration and use 
the correct words "during this execution", or even still use current 
imprecise wording but at least put a clarifying note in the ARM.

Franco Mazzanti