From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sunybcs!planck!hercules.uucp!westley
From: westley@hercules.uucp
Newsgroups: comp.lang.ada
Subject: Missing accept statement
Message-ID: <1990Mar15.203521.28171@planck.uucp>
Date: 15 Mar 90 20:35:21 GMT
Sender: news@planck.uucp (Usenet News)
Reply-To: westley@hercules.uucp ()
Followup-To: comp.lang.ada
Organization: Calspan Corporation ATC  Buffalo, NY
List-Id: <comp.lang.ada>

The following program compiled and ran successfully on a Sun 4 with the
Verdix 6.0(g) Ada compiler.  There were no compilation errors, no
exceptions, and "A_Task" was put.

with Text_IO;

procedure Missing_Task_Entry is

   task A_Task is
      entry Missing_Entry;
   end A_Task;

   task body A_Task is
   begin -- A_Task
      Text_IO.Put_Line ("A_Task");
   end A_Task;

begin -- Missing_Task_Entry
   null;
end Missing_Task_Entry;

Is it valid for a task body to be lacking an accept statement for a
corresponding entry from the specification of that task?  I can't find a
specific rule in the RM, but this seems contrary to idea of the compiler
catching this class of potential bugs.

Terry J. Westley
Arvin/Calspan Advanced Technology Center
P.O. Box 400, Buffalo, NY 14225
acsu.buffalo.edu!planck!westley@hercules