Why must setjmp be a macro?

Dolf Grunbauer dolf at idca.tds.PHILIPS.nl
Thu Jun 28 18:01:12 AEST 1990


In article <96mU02e8b3f201 at amdahl.uts.amdahl.com> nw at uts.amdahl.com (Neal Weidenhofer) writes:
<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."
<>  
<> 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.

You also cannot use 'setjmp' as a function argument when it is macro (oh well,
this is the same as using it as a pointer).

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.
-- 
Dolf Grunbauer      Tel: +31 55 433233 Internet dolf at idca.tds.philips.nl
Philips Information Systems            UUCP     ...!mcsun!philapd!dolf
Some kind of happiness is measured out in miles



More information about the Comp.lang.c mailing list