Why must setjmp be a macro?

[Henry Spencer]

In article <1066 at ssp11.idca.tds.philips.nl> dolf at idca.tds.PHILIPS.nl (Dolf Grunbauer) writes:
>[pointers to setjmp]
>My question is: why can't some architectures support this ? Sounds very weird
>to me as 'setjmp' only stores some registers in a user supplied buffer. Could
>you give some examples.
>
>The fact that some 'implementations' can't handle it sounds like a bug in this
>implementation IMHO. This could never be a reason why ANSI wanted it to be a
>macro.

>From the Rationale, 4.6:

	setjmp is constrained to be a macro only:  in some implementations
	the information necessary to restore context is only available
	while executing the function making the call to setjmp.

Decrypting that somewhat :-), the problem is that setjmp may need special
handling from the compiler.  You can usually implement setjmp as just an
ordinary function, *if* the compiler is not doing serious optimizing.
If heavy optimization is being done, life is much easier if the compiler
knows that a particular function call is in fact a call to setjmp, so it
can take special precautions.

For example, many compilers want to offer rather stronger guarantees about
the values of local variables after longjmp than ANSI C requires (if for
no other reason, because old code will break otherwise -- X3J11 bungled
this one), and it's very difficult to do that in an optimizing compiler
if setjmp is just another function.  Doing it really right requires saving
and restoring all registers around any calls to other functions in the
function that calls setjmp, but that is much too expensive to do in the
absence of setjmp, so the compiler has to know whether there's a setjmp
there or not.
-- 
"Either NFS must be scrapped or NFS    | Henry Spencer at U of Toronto Zoology
must be changed."      -John Osterhout |  henry at zoo.toronto.edu   utzoo!henry