!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) @drepl 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. @dby 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. ****************************************************************