Path: utzoo!attcan!uunet!bu.edu!snorkelwacker!apple!amdahl!nw
From: nw@uts.amdahl.com (Neal Weidenhofer)
Newsgroups: comp.lang.c
Subject: Re: Why must setjmp be a macro?
Summary: To prevent indirect calls
Message-ID: <96mU02e8b3f201@amdahl.uts.amdahl.com>
Date: 28 Jun 90 02:22:38 GMT
References: <5900.267B9A67@puddle.fidonet.org>
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 48

In article <5900.267B9A67@puddle.fidonet.org>, cspw.quagga@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@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