Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!cadre!pitt!darth!tl-vaxa!lindsay
From: lindsay@tl-vaxa.UUCP (Don Lindsay)
Newsgroups: net.lang.c
Subject: Re: functions that don't return
Message-ID: <28@tl-vaxa.UUCP>
Date: Fri, 19-Sep-86 22:30:46 EDT
Article-I.D.: tl-vaxa.28
Posted: Fri Sep 19 22:30:46 1986
Date-Received: Sun, 21-Sep-86 18:48:48 EDT
References: <1074@dataio.UUCP> <86900032@haddock>
Reply-To: lindsay@tl-vaxa.UUCP (Don Lindsay)
Organization: Tartan Laboratories, Pittsburgh, Pa.
Lines: 22
Summary: yes, they do.

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). 

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 !

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.

Don Lindsay