From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 16 Dec 92 16:32:42 GMT From: olivea!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!asuvax!ennews !enuxha.eas.asu.edu!koehnema@ames.arc.nasa.gov (Harry Koehnemann) Subject: Re: Language pitfalls (was Re: FORTRAN bug) Message-ID: <1992Dec16.163242.18923@ennews.eas.asu.edu> List-Id: In article eachus@oddjob.mitre.org (Rob ert I. Eachus) writes: >In article <1992Dec15.203558.18211@inmet.camb.inmet.com> stt@spock.camb.inmet. com (Tucker Taft) writes: > > Oh boy. That is a nasty one. This argues for a "friendly" > Ada compiler giving a warning about any use of "null;" other > than the idiomatic ones like "when others => null;" or "begin null; end;" > (especially in a function that returns an access type ;-). > > Actually, there is an Ada rule which normally catches this, and >which Robert Dewar and I have argued should be removed in Ada 9X. (A >function must contain a return statement RM 6.5(1).) If it belongs on >the top ten list, then the rule should stay. The "null;"/"return null;" was a problem with the base case in a recursive function (null is overloaded, and even worse it's an expression *and* a statement - isn't that something we hate about C :). This implies there will be additional returns somewhere in the routine and it will not be caught by the compiler. The real problem is that there exists an execution path that can lead out of the function without encountering a return. And, won't Ada catch this at run-time? Granted it would be nice for the language to catch it at compile time, but the compiler could easily print a warning saying that such a path exists. -- Harry Koehnemann Arizona State University koehnema@enuxha.eas.asu.edu Computer Science Department