Version 1.1 of acs/ac-00126.txt

Unformatted version of acs/ac-00126.txt version 1.1
Other versions for file acs/ac-00126.txt

!standard H.2(1)          06-01-06 AC95-00126/01
!class Amendment 06-01-06
!status received no action 06-01-06
!status received 05-12-23
!subject Unspecified
!summary
!appendix

From: Robert Dewar
Date: Friday, December 23, 2005  8:23 AM

THere is one use of unspecified in the entire Ada 95 document, namely
the requirement in H.2 that you document anything that is unspecified.

That's a nice glitch :-)

****************************************************************

From: Randy Brukardt
Date: Friday, December 23, 2005  1:33 PM

Huh? The search engine finds 22 clauses with occurrences of the word in the
Ada 95 RM: 1.1.1(14); 7.2(5); 6.2(11); 4.5.5(21); 11.1(6); and even H(4.1),
just to name a few.

> That's a nice glitch :-)

I think the glitch is with your search tool...

****************************************************************

From: Robert Dewar
Date: Friday, December 23, 2005  9:13 PM

Indeed, don't know what went wrong, BUT, we have the following:

18   Certain aspects of the semantics are defined to be either implementation
defined or unspecified.  In such cases, the set of possible effects is
specified, and the implementation may choose any effect in the set.
Implementations shall document their behavior in implementation-defined
situations, but documentation is not required for unspecified situations.
The implementation-defined characteristics are summarized in Annex M.

1   The implementation shall document the range of effects for each situation
that the language rules identify as either a bounded error or as having an
unspecified effect.  If the implementation can constrain the effects of
erroneous execution for a given construct, then it shall document such
constraints.  The documentation might be provided either independently of any
compilation unit or partition, or as part of an annotated listing for a given
unit or partition.  See also 1.1.3, and 1.1.2.

Clearly these are incompatible. , what's the story????

****************************************************************

From: Pascal Leroy
Date: Monday, January  2, 2006  6:43 AM

> Clearly these are incompatible. , what's the story????

I think the intent is clear.  In general we don't require implementations
to document their "unspecified" behavior, but implementations that claim
conformance to annex H must do so.  So I am not terribly concerned about
the inconsistency between 1.1.3(18) and H.2(1).

What concerns me more is that H.2(1) seems like an unreasonable
requirement.  There are very many situations where we say "unspecified"
(look at the index) and documenting all of them seems daunting, and
probably not too useful.  For instance, if the Hash function passed to the
containers packages is broken, the behavior of these packages is
unspecified.  Do we really believe that documenting what happens in this
situation would help high-integrity applications?  I don't think so.

In fact the note in H.2(2) and the associated AARM notes are much more
useful, because of talking about the places where the word "unspecified"
appears, they mention specific examples which are actually significant for
high-integrity applications.

Overall, it looks like H.2 would be much more useful if it were worded as
an Implementation Requirement mentioning the actual stuff that we want
implementations to document.

****************************************************************

From: Robert Dewar
Date: Monday, January  2, 2006  6:51 AM

>What concerns me more is that H.2(1) seems like an unreasonable
>requirement.  There are very many situations where we say "unspecified"
>(look at the index) and documenting all of them seems daunting, and
>probably not too useful.  For instance, if the Hash function passed to the
>containers packages is broken, the behavior of these packages is
>unspecified.  Do we really believe that documenting what happens in this
>situation would help high-integrity applications?  I don't think so.

Well it would be unreasonable, if documentation requirements meant anything at
all, which they really don't, since as requirements they are untestable. We
take the position with GNAT that we document everything by giving you the full
sources. Might not be the most convenient form for some of the documentation,
but it's impossible for the RM to even specify what documentation means let
alone what convenient means. My view is that all documentation requirements
have no place in the RM. The market should decide what documentation is or is
not helpful or needed.

>Overall, it looks like H.2 would be much more useful if it were worded as
>an Implementation Requirement mentioning the actual stuff that we want
>implementations to document.

I doubt this is worth the effort, considering the above point.

****************************************************************

From: Robert A. Duff
Date: Monday, January  2, 2006  9:21 AM

> Well it would be unreasonable, if documentation requirements meant
> anything at all, which they
> really don't, since as requirements they are untestable.

Yes.  I think the ARG should not waste time improving the Doc Requirements.
Unless, of course, I can convince you all that we should delete them entirely.  ;-)

>...We take the position with GNAT that we
> document everything by giving you the full sources.

Alternatively, we could satisfy H.2 by telling users to go look at the
generated object code for their program.  H.2(2.c) even hints that something
like that might be the best approach.

The note in H.2(2) seems somewhat misguided.  Whether the things mentioned would
be usefully documented depends on the program.  Many safety-critical apps avoid
heap usage, in which case it's pointless to document the heap algorithms.
And if you use SPARK, you don't care about the parameter passing mechanisms,
because SPARK lets you prove that they don't matter.

****************************************************************


Questions? Ask the ACAA Technical Agent