CVS difference for ais/ai-00278.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00278.txt

--- ais/ai-00278.txt	2001/10/17 21:25:00	1.1
+++ ais/ai-00278.txt	2001/10/19 01:36:44	1.2
@@ -235,6 +235,53 @@
 
 *************************************************************
 
+From: Ted Baker
+Sent: Thursday, October 18, 2001  7:05 AM
+
+I agree with you.  The latter is better.
+
+*************************************************************
+
+From: David Emery
+Sent: Thursday, October 18, 2001 12:23 PM
+
+What I prefer is adding comments to make things clear:
+
+	if <something> then
+		return <something else>;
+  	end if;  -- <something>
+
+	-- if we get here then it's not <something>
+	[lengthy sequence of statements]
+
+Although I've more often done the following (notice comments)
+
+	If <something> then
+		[bunch of statements]
+	else -- not <something>
+		[lots more statements]
+	end if;  -- <something>
+
+And as a rule of thumb, if either [bunch of statements] or
+[lots more statements] are more than a page, I'll consider
+making a nested subprogram to encapsulate the linear
+sequence of statements, to make the control flow more clear:
+
+	if <something> then
+		first_bunch_of_statements;
+	else -- not <something>
+		second_bunch_of_statements;
+	end if; -- <something>
+
+I also tend to lean on pretty-printing/indentation to make
+the control flow comb a little clearer.  But this only works
+about 2-3 levels deep max on a single page or maybe 2 pages max.
+
+But good style is the opinion of the ranking person reading the
+code :-)
+
+*************************************************************
+
 From: Randy Brukardt
 Sent: Tuesday, October 16, 2001  1:06 PM
 
@@ -348,6 +395,32 @@
 to terminate, and be sure that it works in all cases, even if the task is
 aborted, and without race condition? Easy, call an entry of the task that is
 never accepted, and catch Tasking_Error...
+
+*************************************************************
+
+From: Ted Baker
+Sent: Thursday, October 18, 2001  7:02 AM
+
+| Yes, I should have pointed out the rules instead of notes. Any way, it does
+| not make sense that declared entry could have no corresponding accept
+| statement. Then, task entry has no value, or it is a dead code. However,
+| dead code does not cause task deadlock. But, dead task entry code does.
+| Therefore, it is much danger not to change it since it costs time, money and
+| headache.
+
+| I do not quite understand why it is tricky to write a rule requiring that
+| there is at least one corresponding accept statement for each declared entry.
+| In fact, why is it easy to write a rule requiring that there is one body
+| subprogram for one or none spec. subprogram?
+
+1) Such a rule would only catch the most obvious kind of error.  In real life
+   with experienced programmers deadlocks occur for more subtle reasons.
+
+2) There actually are situations where it is useful to have an
+   entry with no accept, that can be used to block a task forever (or until
+   it gets an asynchronous exception).
+
+3) A compiler can always provide an advisory warning message about this case.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent