Re: Language pitfalls (was Re: FORTRAN bug)

[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)]

In article <EACHUS.92Dec15202249@oddjob.mitre.org> 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