🚀 go-pugleaf

tl-vaxa!lindsay (Don Lindsay) writes:
>There has been some discussion about functions that never return (e.g exit).
>It was suggested that if a compiler could be told about this, then it
>could generate better code.
>
>In fact, these functions sometimes DO return (and in that case, the compiler
>had better have allowed for that).

Hogwash.  "Functions that never return" and "functions that sometimes DO
return" describe disjoint sets.  Functions genuinely in the latter set (e.g.
pre-ANSI abort()) are not under consideration here.

>For example, a storage allocator may decide to exit, because his caller has
>reached some limit.  But, the developer of this storage allocator wishes to
>write a test program, and she wants the test program to exercise this
>feature.  The test program can be more powerful, and more convenient, and
>easier to document and use, if it can make the "exit" routine return!

What if the function that calls exit() doesn't fall into a return?  (E.g.
"if (p == NULL) exit(1); *p = ..." will bomb if exit() doesn't exit.)  And
if you supersede exit() with a function that returns, how do you get out of
the program?  Send yourself a signal?

>Similarly, a program may detect an unusual condition, and call a handler
>for it. It is more general if it is the handler which decides whether or
>not to return. (Perhaps one would link in different handlers under different
>circumstances.) It is quite common for people to write over-specified
>programs, where the mainline "knows" what kind of handler is out there.
>The existence of a new function type would mostly encourage such limited
>thinking.

On the contrary, it would encourage the author to document (via declaration)
what the specification is.  It's the author's right to insist on a handler
that doesn't return, if there's no appropriate default handler.  (A storage
allocator normally does have an appropriate default handler: "return (NULL)")

You might as well be arguing that "void" is a bad idea because it encourages
people to write functions that don't return an error check.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint