Why must setjmp be a macro?

Neal Weidenhofer nw at uts.amdahl.com
Thu Jun 28 12:22:38 AEST 1990


In article <5900.267B9A67 at puddle.fidonet.org>, cspw.quagga at p0.f4.n494.z5.fidonet.org (cspw quagga) writes:
> ANSI seems to insist that setjmp should be a macro.  (4.6 of the
> report and of the Rationale).  But in various places there are
> references to the setjmp function, and the report also says "It
> is unspecified whether setjmp is a macro or an identifier declared
> with external linkage."
>  
> I looked at three compilers all claiming to be ANSI, and they all
> implemented setjmp as a function, not as a macro.
>  
> Are there any possible differences that a program could discern
> between macro/function implementations in this case (other than
> being able to suppress a macro definition with #undef?)
>  
> Why would ANSI insist that something must be a macro?

One very important thing that you CAN'T do with a macro is put its
address in a pointer and call it through the pointer:

	int (*sj)() = setjmp;

is legal if setjmp is a function, not legal if it is a macro.  Some
architectures and implementations can't handle this kind of indirect
call to setjmp.  As I remember the debate, making setjmp a macro was
to allow these implementations to call themselves ANSI-compliant
because they knew that no strictly conforming program could use this
construct.

> So does the description "macro" actually mean
>   "You are free to implement this as a function, but you may
>    assume no more than a macro?"

In this case it means for the implementation that you can call it a
function if and only if you can handle the above construct.  You might
run this by the three compilers you mentioned above.

> EP Wentworth - Dept. of Computer Science - Rhodes University - Grahamstown.

The opinions expressed above are mine (but I'm willing to share.)

			Regards,
And while the future's          Neal Weidenhofer
	there for anyone        nw at amdahl.uts.amdahl.com
To change, still you            Amdahl Corporation
	know it seems           P. O. Box 3470
It would be easier sometimes    1250 E. Arques Ave. (M/S 316)
	to change the past.     Sunnyvale, CA 94088-3470
				(408)737-5007



More information about the Comp.lang.c mailing list