AI22-0058-1

!standard C.7.1(4/3)                                      22-01-11  AI22-0058-1/01

!standard D.2.6(9/5)

!standard D.2.6(29/2)

!standard D.5.1(4)

!standard D.5.1(5)

!standard D.5.1(9)

!standard D.11(3/5)

!standard D.11(9)

!standard D.14(5/2)

!standard D.14(17/2)

!class Binding Interpretation 22-01-11

!status work item 22-01-11

!status received 22-01-11

!priority Low

!difficulty Easy

!qualifier Clarification

!subject Preconditions for checking Task_Ids

!summary

Preconditions, rather than wording, are used to check Task_Ids in various

Annex D subprograms.

!issue

Ada 202y is attempting to use preconditions and postconditions as much as possible. The following rule appears in a number of places in Annex D:

For all the operations defined in <<some package>>, Tasking_Error is raised if the task identified by T has terminated. Program_Error is raised if the value of T is Null_Task_Id.

This would be better described by a precondition.

!recommendation

Add preconditions to various subprograms in Annex D.

!wording

Add:

to Set_Deadline, Get_Deadline, Set_Relative_Deadline, Get_Relative_Deadline, Get_Last_Release_Time in D.2.6(9/5); to Set_Priority in D.5.1(4); to Get_Priority in D.5.1(5); to Hold, Continue, and Is_Held in D.11(3/5); and to Clock in D.14(5/2).

In AARM D.5.1(12.a):

Replace  "the above rule saying" with "the precondition".

Delete D.2.6(29/2), D.5.1(9), D.11(8).

Modify D.14(17/2):

The function Clock returns the current execution time of the task identified by T[; Tasking_Error is raised if that task has terminated; Program_Error is raised if the value of T is Task_Identification.Null_Task_Id].

!discussion

The original English-language rule is backwards - one has to check for Null_Task_Id before checking whether a task is terminated.

Ada.Task_Identification.Is_Terminated is defined to raise Program_Error when passed a Null_Task_Id, so we do not need to handle that case explicitly. As such, this makes no semantic change (assuming a sensible reading of the original text).

[Editor's note: Since this makes no semantic change, it is classified as a Binding Interpretation. It could even be considered a presentation change, except that this does open the possibility of Suppressing the precondition check. Note, however, that there is no check name defined for the packages defined in the various annexes (that seems to be an omission, but one that should be

considered on its own merits in a separate AI).]

!ACATS test

No semantic change is intended, so existing tests (if they exist) should cover this case.

!appendix

This AI was promoted from AI12-0316-1 to be reconsidered for post-Ada 2022 work. The !appendix of the original AI has additional motivation and discussion.

This version of the AI was rewritten to use the suggestion from Randy Brukardt of February 26, 2019 to simplify the change and overcome objections raised during Meeting #60D.