Interpretation of LRM 13.10.1

[NCOHEN@IBM.COM ("Norman H. Cohen")]

13.10.1(8) is one of the most often misinterpreted paragraphs in the RM.
(Fortunately, it's a note, and therefore not officially part of the
language definition.  LRM 2.7(1) states, "Furthermore, comments do not
influence the effect of a program; their sole purpose is the
enlightenment of the human reader."  John Goodenough once quipped that
the LRM Note paragraphs do not influence the definition of the language;
their sole purpose is to confuse the reader.)

There are two sources of confusion:

1. Informally, we often use the word "task" to mean a task unit or a
   task object.  However, in the (usually) precise language of the LRM,
   a "task" in Ada is neither an object nor a program unit, but a process
   (a thread of control).  A TASK OBJECT "designates" some task.
   (See 9(2) and 9.2(2).)

2. The word "designates" also has another technical meaning in the LRM:
   An access value "designates" the object it points to (see 3.8(1)).
   Unfortunately, the word "designates" is used in both senses in the
   first sentence of 13.10.1(8).

Now lets look at the first sentence of 13.10.1(8):

   If X designates a task object, the call FREE(X) has no effect on
   the task designated by the task object.

(Here X is an access value and FREE is an instance of
UNCHECKED_DEALLOCATION.)  An informal paraphrase is:

   If X points to a task object, the call FREE(X) has no effect on
   the thread of control corresponding to that task object.

Thus, for example, you can't abort a task by attempting to deallocate it.

When an instance of UNCHECKED_DEALLOCATION is applied to a task object
designating a terminated task, a good compiler will reclaim the storage
occupied by the task object.  Not all compilers are good.

Norman H. Cohen