CVS difference for ai05s/ai05-0004-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0004-1.txt

--- ai05s/ai05-0004-1.txt	2006/04/20 05:30:39	1.2
+++ ai05s/ai05-0004-1.txt	2006/05/12 20:28:09	1.3
@@ -1,5 +1,6 @@
-!standard 1.1.3   (17)                               06-03-15  AI05-0004-1/00
+!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
@@ -10,9 +11,13 @@
 
 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.)
 
-[This is a placeholder for the certain flood of errors.]
+[Other questions here.]
 
 !recommendation
 
@@ -20,9 +25,26 @@
 
 !wording
 
+1) C.7.1(17/2) should say entry_body rather than entry body.
+
 !discussion
 
-!comment !corrigendum 1.1.3(17)
+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
 
@@ -80,6 +102,109 @@
 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