Version 1.3 of ai05s/ai05-0004-1.txt
!standard C.7.1(17/2) 06-05-12 AI05-0004-1/01
!class presentation 06-03-15
!status work item 06-05-12
!status received 06-03-15
!priority Low
!difficulty Easy
!qualifier Omission
!subject Presentation issues in the Standard.
!summary
This AI corrects minor errors in the Standard.
1) C.7.1(17/2) should say entry_body rather than entry body.
!question
1) Does C.7.1(17/2) apply to calls to Current_Task in an entry barrier? (Yes.)
[Other questions here.]
!recommendation
(See summary.)
!wording
1) C.7.1(17/2) should say entry_body rather than entry body.
!discussion
1) entry_barrier is syntactically within entry_body. C.7.1(17/2) however, says
"entry body", which is not defined by the Standard. The most reasomable assumption
is that "entry_body" was meant, especially as the intent is that barriers may be
evaluated by any task. We therefore avoid confusion by changing the wording to use
the syntax term.
!corrigendum C.7.1(17/2)
Replace the paragraph:
It is a bounded error to call the Current_Task function from an entry body, or an
interrupt handler, or finalization of a task attribute. Program_Error is raised,
or an implementation-defined value of the type Task_Id is returned.
by:
It is a bounded error to call the Current_Task function from an @fa{entry_body}, or an
interrupt handler, or finalization of a task attribute. Program_Error is raised,
or an implementation-defined value of the type Task_Id is returned.
!ACATS test
None needed.
!appendix
From: Tucker Taft
Sent: Wednesday, April 12, 2006 12:48 PM
We have a relative newcomer to Ada doing some of
our Ada 2005 work, and it is useful because it forces
me to actually *read* what we have written in the
reference manual. I came upon this wording in 4.6(24.*):
If there is no type that is the ancestor of both
the target type and the operand type, and they are
not both class-wide types, one of the following
rules shall apply:
* If the target type is a numeric type, ...
* If the target type is an array type, ...
* If the target type is universal access, ...
* If the target type is a general access...
* If the target type is a pool-specific access...
* If the target type is an access-to-subprogram...
In explaining this to our engineer, I found the introductory
paragraph to be a confusing way of putting things. In our
next revision, I would suggest we reword the introductory
paragraph roughly as follows:
If there is no type that is the ancestor of both
the target type and the operand type, and they are
not both class-wide types, then the target type
shall be a numeric type, an array type, or
an access type; further: ... [same bullets as before]
As introduced now, you have to read all of the following bullets
to figure out what kind of types *might* be covered by these
set of rules, and we are relying on the phrase
"one of the following shall apply" to effectively say that
record types do not allow conversions other than those
allowed for in 4.6(21-23.1). And there are a lot of rules to
read (not just the six abstracted above), since most of the rules
have several sub-bullets. For example, are all access types
(including anonymous ones) covered by at least one of the rules?
It takes some time to decide. In general, as written the
introductory paragraph seems to put an undue and unnecessary
burden on the reader to decide whether exactly one of the rules
applies to any given situation.
For what it is worth, the specific case we wanted to know
about was conversion between an interface and a non-interface
type. You can easily get lost in the long-winded rules
relating to access types and think that your case might
be covered.
****************************************************************
From: Pascal Obry
Sent: Monday, May 8, 2006 12:48 PM
The ARM C.7.1, par. 17 says :
<<
It is a bounded error to call the Current_Task function from an entry
body, interrupt handler, or finalization of a task attribute.
Program_Error is raised, or an implementation-defined value of the
type Task_Id is returned.
>>
What about calling Current_Task from an entry barrier ? Is that a
bounded error too ? In this case it should be clearly documented.
****************************************************************
From: Robert A. Duff
Sent: Monday, May 8, 2006 6:40 PM
I don't know what the right answer is.
Why are any of these cases bounded errors? I mean, why not require it to
return some implementation-defined task, in cases where we don't specify which
task executes a particular piece of code? It might even be useful to find out
which task that is -- for example, in the interrupt handler case, mightn't it
be useful to find out which task was interrupted (impl def, of course)?
****************************************************************
From: Randy Brukardt
Sent: Monday, May 8, 2006 7:01 PM
Because that's what Ada 95 chose to do in this case, and there never has
been a compelling reason to change that decision. My understanding is that
these operations not only might be executed by some other task, but they
might be executed by something that is not a task at all (in the sense of
having a TCB, etc.). In that case, raising Program_Error seems like the only
sensible thing to do.
In any case, we shouldn't be changing things like this unless we have to
(why break people's runtimes for trivalities?). It doesn't make sense to
call Current_Task in an entry body anyway; the attribute 'Caller is provided
for this purpose.
****************************************************************
From: Randy Brukardt
Sent: Monday, May 8, 2006 7:08 PM
> What about calling Current_Task from an entry barrier ? Is that a
> bounded error too ? In this case it should be clearly documented.
An entry barrier is syntactally part of an entry body, so I would say that
the rule already covers it by the wording you give. The only question in my
mind is whether "entry body" was supposed to be "entry_body" (there is no
"entry body" defined in Ada [at least, there isn't a definition in the
index]) -- but that seems like hair-splitting. I suppose an AARM note
pointing that "entry body" includes entry barriers wouldn't be a bad idea.
****************************************************************
From: Adam Beneschan
Sent: Monday, May 8, 2006 7:12 PM
> What about calling Current_Task from an entry barrier ? Is that a
> bounded error too ? In this case it should be clearly documented.
Looking at 9.5.2(5), it appears that an entry barrier is syntactically
part of an entry body (or, at least, an entry_body; I think they're
the same thing), so perhaps we should assume that C.7.1(17) would
apply to an entry barrier also, since a call to Current_Task from an
entry barrier *is* a call from an entry body since the entry barrier
is part of the entry body. Anyway, that seems to be the most sensible
interpretation, especially since it leads to the correct result :)
****************************************************************
From: Randy Brukardt
Sent: Monday, May 8, 2006 7:28 PM
I think there is an echo in here. :-) Needless to say, I agree with Adam.
****************************************************************
From: Tucker Taft
Sent: Monday, May 8, 2006 7:38 PM
> Why are any of these cases bounded errors? I mean, why not require it to
> return some implementation-defined task, in cases where we don't specify which
> task executes a particular piece of code? It might even be useful to find out
> which task that is -- for example, in the interrupt handler case, mightn't it
> be useful to find out which task was interrupted (impl def, of course)?
We have generally made things bounded errors when there is
no obvious right and/or meaningful answer, but we don't
want it to be erroneous. The other reason to make it a
bounded error is the hope that it reduces the chance that
implementations are forced to do something expensive but
useless.
****************************************************************
Questions? Ask the ACAA Technical Agent