Path: utzoo!attcan!uunet!mcsun!hp4nl!philapd!ssp11!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.lang.c
Subject: Re: Why must setjmp be a macro?
Message-ID: <1066@ssp11.idca.tds.philips.nl>
Date: 28 Jun 90 08:01:12 GMT
References: <5900.267B9A67@puddle.fidonet.org> <96mU02e8b3f201@amdahl.uts.amdahl.com>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 33

In article <96mU02e8b3f201@amdahl.uts.amdahl.com> nw@uts.amdahl.com (Neal Weidenhofer) writes:
<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."
<>  
<> 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@idca.tds.philips.nl
Philips Information Systems            UUCP     ...!mcsun!philapd!dolf
Some kind of happiness is measured out in miles