Version 1.10 of ais/ai-00241.txt

Unformatted version of ais/ai-00241.txt version 1.10
Other versions for file ais/ai-00241.txt

!standard 11.4.1 (14)          01-09-11 AI95-00241/03
!class binding interpretation 00-11-19
!status Amendment 200Y 02-05-09
!status WG9 Approved 01-10-05
!status ARG Approved 9-0-1 00-11-19
!status work item 00-10-04
!status received 00-10-04
!priority Medium
!difficulty Easy
!subject Testing for Null_Occurrence
!summary
The function Exception_Identity applied to Null_Occurrence returns Null_Id, which can then be tested using the equality operation.
!question
Ada.Exceptions exports the constant Null_Occurrence, but doesn't provide any way to test whether a given exception occurrence is Null_Occurrence (type Exception_Occurrence is limited). Is this intended? (No.)
!recommendation
The call Exception_Identity(X), where X has the value Null_Occurrence, should not raise Constraint_Error, but return the value of Null_Id which can then be tested against Null_Id using the equality operation.
!wording
Replace 11.4.1(14) by
Raise_Exception and Reraise_Occurrence have no effect in the case of Null_Id or Null_Occurrence. Exception_Name raises Constraint_Error for a Null_Id. Exception_Message, Exception_Name, and Exception_Information raise Constraint_Error for a Null_Occurrence. Exception_Identity applied to Null_Occurrence returns Null_Id.
!discussion
When logging information, an application probably will use Null_Occurrence to represent the absence of an exception.
When displaying the log, it is necessary to determine whether a particular occurrence is Null_Occurrence or an occurrence containing information about an exception.
Currently, it is difficult to test for Null_Occurrence because, being of a limited type, it is not possible to compare with the constant Null_Occurrence. Moreover, the function Exception_Identity applied to Null_Occurrence raises Constraint_Error. An exception handler can be used to detect this but it is awkward, does not reflect that this is a normal case, and potentially can mask other errors.
Two alternatives were considered. One was to add a function Is_Null_Occurrence and the other was to define Exception_Identity to return Null_Id when applied to Null_Occurrence rather than raise Constraint_Error.
The second approach was taken because it avoids adding a further function and moreover it seems unnatural that Exception_Id(Null_Occurrence) should raise Constraint_Error.
An instance of Null_Occurrence can be tested for as in the following:
procedure Process_Exception(X: Exception_Occurrence) is begin if Exception_Identity(X) = Null_Id then -- process the case of a Null_Occurrence else -- process other exception occurrences end if; end;
!corrigendum 11.4.1(14)
Replace the paragraph:
Raise_Exception and Reraise_Occurrence have no effect in the case of Null_Id or Null_Occurrence. Exception_Message, Exception_Identity, Exception_Name, and Exception_Information raise Constraint_Error for a Null_Id or Null_Occurrence.
by:
Raise_Exception and Reraise_Occurrence have no effect in the case of Null_Id or Null_Occurrence. Exception_Name raises Constraint_Error for a Null_Id. Exception_Message, Exception_Name, and Exception_Information raise Constraint_Error for a Null_Occurrence. Exception_Identity applied to Null_Occurrence returns Null_Id.
!ACATS test
Add a test case to CB41004 to check that Exception_Identity(Null_Occurrence) does return Null_Id.
!appendix

!topic Testing for Null_Occurrence
!reference RM95-11.4.1(3)
!from Gary Dismukes (for Ada Core Technologies)
!keywords Ada.Exceptions, Null_Occurrence
!discussion

Ada.Exceptions exports the constant Null_Occurrence, but doesn't
provide any way to test whether a given exception occurrence is
Null_Occurrence (type Exception_Occurrence is limited).

We propose that a function should be added to Ada.Exceptions that
would allow testing whether an exception occurrence is
Null_Occurrence.
In GNAT, we have added a child function
Ada.Exceptions.Is_Null_Occurrence
for this purpose:

--  This is a GNAT-specific child function of Ada.Exceptions. It
provides
--  clearly missing functionality for its parent package, and most
reasonably
--  would simply be an added function to that package, but this
change cannot
--  be made in a conforming manner.

function Ada.Exceptions.Is_Null_Occurrence
  (X    : Exception_Occurrence)
   return Boolean;
   --  This function yields True if X is Null_Occurrence, and False
otherwise

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

From: Tucker Taft
Sent: Friday, September 22, 2000 9:19 PM

I believe the original intent was that:

   Exception_Identity(Null_Occurrence) = Null_Id

providing a mechanism for testing for Null_Occurrence,
but I see that 11.4.1(14) contradicts that by indicating that
Exception_Identity raises Constraint_Error in this case.  I think
that is a mistake, though others might remember otherwise.

> function Ada.Exceptions.Is_Null_Occurrence
>   (X    : Exception_Occurrence)
>    return Boolean;
> --  This function yields True if X is Null_Occurrence, and False
otherwise

This seems like a reasonable proposal, in any case, although it
is obviously an amendment, not an interpretation.

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

From: Robert Dewar
Sent: Friday, September 22, 2000 10:03 PM

<<I believe the original intent was that:

   Exception_Identity(Null_Occurrence) = Null_Id

providing a mechanism for testing for Null_Occurrence,
but I see that 11.4.1(14) contradicts that by indicating that
Exception_Identity raises Constraint_Error in this case.  I think
that is a mistake, though others might remember otherwise.
>>

Well I would be happy to allow this identity, though this would be a change
(in GNAT we could add a child, but not change clear RM semantics), but
if one is in the amendment business, perhaps allowing the above identity
is the cleanest approach.

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

From: Robert Dewar
Sent: Sunday, May 1, 2005  7:00 AM

This is rated as easy, but in fact it's one of the nastiest AI's
I have run across so far. Why? Because it requires clearly
incompatible behavior between Ada 95 and Ada 2005 at run time,
and we have not encountered this requirement yet, which will
require a completely new mechanism in the compiler.

Are we sure that was the intention here.

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

From: Bob Duff
Sent: Sunday, May 1, 2005  9:09 AM

True, but changing an exception to some reasonable behavior is not as
bad as changing behavior in other ways.  I think we did that in
various ways in the 83-to-95 change.

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

From: Robert Dewar
Sent: Sunday, May 1, 2005  6:49 PM

Yes, I agree, and that is why I think we should allow this new
preferable behavior to be implemented in Ada 95 compilers.

Presumably however, the worry is that existing code tests for
a null exception precisely by catching the expected exception,
so the change is indeed potentially incompatible.

In fact once I think in those terms, it seems that this AI is
really proposing a *quite* incompatible change.

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

From: Randy Brukardt
Sent: Sunday, May 1, 2005  6:57 PM

> Are we sure that was the intention here.

Yes.

Two points:

This AI is a binding interpretation; it applies to Ada 95 as well as Ada
2006. So there is no inconsistency in that sense (even though it is
documented in the AARM as one). An implementation of either language that
raises an exception in this case is wrong. Indeed, I've long since removed
the part of the ACATS test that required an exception to be raised (whether
it is ever replaced by a test requiring the new behavior remains to be
seen). Of course, an implementor can always do whatever they want in a
non-standard mode (including supporting Ada 95 without the most recent set
of BIs), but that's not relevant to how the standard should work.

Second, there are 12 clauses in the draft AARM that contain "Inconsistencies
with Ada 95" items. These of course are run-time differences from Ada 95.
Most of them are obscure cases that ought not come up in practice, but
they're there. There also were several cases where I didn't document a
difference because the construct was erroneous or unspecified in Ada 95; but
code that depends on that anyway might also need to change its effect. (And
it wouldn't surprise me if I missed a couple of inconsistencies when writing
the standard.) So you'll probably need some mechanism for runtime
differences if you intend to support strict Ada 95 compatibility.

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

From: Robert Dewar
Sent: Sunday, May 1, 2005  7:05 PM

> Yes.

I am completely confused, you say Yes above but ...

> Two points:
>
> This AI is a binding interpretation; it applies to Ada 95 as well as Ada
> 2006. So there is no inconsistency in that sense (even though it is
> documented in the AARM as one). An implementation of either language that
> raises an exception in this case is wrong. Indeed, I've long since removed
> the part of the ACATS test that required an exception to be raised (whether
> it is ever replaced by a test requiring the new behavior remains to be
> seen). Of course, an implementor can always do whatever they want in a
> non-standard mode (including supporting Ada 95 without the most recent set
> of BIs), but that's not relevant to how the standard should work.

This clearly says no ... incompatible behavior is not required ...

> Second, there are 12 clauses in the draft AARM that contain "Inconsistencies
> with Ada 95" items. These of course are run-time differences from Ada 95.
> Most of them are obscure cases that ought not come up in practice, but
> they're there. There also were several cases where I didn't document a
> difference because the construct was erroneous or unspecified in Ada 95; but
> code that depends on that anyway might also need to change its effect. (And
> it wouldn't surprise me if I missed a couple of inconsistencies when writing
> the standard.) So you'll probably need some mechanism for runtime
> differences if you intend to support strict Ada 95 compatibility.

What does strict Ada 95 compatibility mean, surely a strictly Ada 95
compatible compiler must implement any binding interpreations issued
by the ARG.

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

From: Randy Brukardt
Sent: Sunday, May 1, 2005  7:33 PM

Robert Dewar wrote:

...
> I am completely confused, you say Yes above but ...

I meant that the behavior is different from that originally defined for Ada
95, and that is intentional.

...
> > So you'll probably need some mechanism for runtime
> > differences if you intend to support strict Ada 95 compatibility.
>
> What does strict Ada 95 compatibility mean, surely a strictly Ada 95
> compatible compiler must implement any binding interpreations issued
> by the ARG.

I don't think anywhere near all of them are caused by BIs. Some of them have
to do with the character set stuff (the behavior of
Wide_Character'Wide_Image for non-graphic characters, for example), and
those clearly aren't BIs. Indeed, I tried not to document differences caused
by BIs (AI-241 being an exception).

So I still think that you'll need a way to select Ada 95 behavior at runtime
if you want strict compatibility. (I'd have to go back and look at all of
them again to see how important that is.)

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

From: Robert Dewar
Sent: Sunday, May 1, 2005  9:14 PM

> I meant that the behavior is different from that originally defined for Ada
> 95, and that is intentional.

Well there are *many* cases of binding interpretations for sure,
but that's not my concern at all.

> I don't think anywhere near all of them are caused by BIs. Some of them have
> to do with the character set stuff (the behavior of
> Wide_Character'Wide_Image for non-graphic characters, for example), and
> those clearly aren't BIs. Indeed, I tried not to document differences caused
> by BIs (AI-241 being an exception).

But that's strictly compile time

> So I still think that you'll need a way to select Ada 95 behavior at runtime
> if you want strict compatibility. (I'd have to go back and look at all of
> them again to see how important that is.)

Well apparently AI-241 is not an example of this. If you think there
is one, I would be interested.

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

From: Randy Brukardt
Sent: Sunday, May 1, 2005  11:32 PM

...
> > I don't think anywhere near all of them are caused by BIs. Some of them
have
> > to do with the character set stuff (the behavior of
> > Wide_Character'Wide_Image for non-graphic characters, for example), and
> > those clearly aren't BIs. Indeed, I tried not to document differences
caused
> > by BIs (AI-241 being an exception).
>
> But that's strictly compile time

Huh? Since when is the result of 'Image (and the strings accepted by 'Value)
"strictly compile-time".

AI-285 (as modified by AI-395) defines the result of 'Image differently for
non-graphic characters than Ada 95 did. It also gets rid of the funny "FFFE"
image.

In particular, Wide_Character'Image(Wide_Character'Pos(16#FFFE#)) = "FFFE"
in Ada 95, and "HEX_0000FFFE" in Ada 2006. And of course 'Value is the
reverse of this.

(This last change wasn't strictly necessary, but once compatibility had been
dropped for other non-graphic characters, there was no benefit to keeping it
for this character, which isn't supposed to ever be used anyway.)

...
> Well apparently AI-241 is not an example of this. If you think there
> is one, I would be interested.

See above. There are other examples in the draft AARM, for instance, an
object can be unconstrained in the heap in certain circumstances, which
would eliminate constraint_errors that would occur in Ada 95 (AI-363). Look
for "Inconsistencies with Ada 95" in the AARM. These are considered the
worst issues, so everything that conceivably could be there is documented
there. At least if I thought of it when adding those AIs.

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

From: Robert Dewar
Sent: Monday, May 2, 2005  6:36 AM

...
> Huh? Since when is the result of 'Image (and the strings accepted by 'Value)
> "strictly compile-time".
>
> AI-285 (as modified by AI-395) defines the result of 'Image differently for
> non-graphic characters than Ada 95 did. It also gets rid of the funny "FFFE"
> image.
>
> In particular, Wide_Character'Image(Wide_Character'Pos(16#FFFE#)) = "FFFE"
> in Ada 95, and "HEX_0000FFFE" in Ada 2006. And of course 'Value is the
> reverse of this.

Well true, but this is too marginal to worry about, no program
is counting on this kind of thing (obviously the ARG feels the
same way, since it feels free to introduce serious casual
incompatibilities in this area :-) Next you will be worrying
about the idiotic Width attribute giving different results
(idiotic, because the business of dealing at run time with
dynamic subtypes is absurd).

I would actually specifically allow compilers to adopt the new
behavior for image in Ada 95, just as we allowed Ada 83 compilers
to move to 8-bit characters before Ada 95 appeared.

> See above. There are other examples in the draft AARM, for instance, an
> object can be unconstrained in the heap in certain circumstances, which
> would eliminate constraint_errors that would occur in Ada 95 (AI-363). Look
> for "Inconsistencies with Ada 95" in the AARM. These are considered the
> worst issues, so everything that conceivably could be there is documented
> there. At least if I thought of it when adding those AIs.

The unconstrained objects on the heap business (what an awful junk
change to the language -- first time that making a type private
completely changes its behavior -- and a serious incompatibility
with Ada 95) is compile time only, since you know at compile time
what types are affected, I don't see any point at which there would
be an issue here requiring a run-time check, or different run times.

We really don't want run-time penalties for compilers that try to
accomodate Ada 95 and Ada 2005 at the same time, since this is the
natural way to encourage transition.

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


Questions? Ask the ACAA Technical Agent