🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #4333

Re: setjmp.h

#4333
From: Terry Colligan
Date: Mon, 06 Nov 1995 02:25
75 lines
2736 bytes
In <815323606snz@soliton.demon.co.uk> Ian Cargill
<ian@soliton.demon.co.uk> writes: 
>
>In article <478bqi$nb3@rdsunx.crd.ge.com>
>           volpe@ausable.crd.ge.com "Christopher R. Volpe" writes:
>
(snip)
>
>Sorry, It was a woefully inadequate question.  I'll do what I should 
>have done in the first place and state it in full.
>
>I know a (non-static) function designator would qualify as an
identifier 
>with external linkage, but if the intention is simply to allow a
function, 
>why do it this way?
>
>If it is OK to make setjmp a function, why define it as being a macro,

>in 7.6.1.1?  The only other things defined this way are assert,
va_arg, 
>va_start and va_end, all of which must be macros.  If you want to
allow 
>it to be either a macro or a function, why use this special wording?
>Why not just specify it in the same way as other things which can be 
>function and/or macros? (i.e. most functions)  
>
>If 7.6.1.1 refered to 'The setjmp function' instead of 'The setjmp
macro', 
>7.1.7 would still permit a macro version.  Admittedly, there is a
slight 
>difference.  In this case, you might want a macro OR a function, but
not 
>both, but you could cover that with a constraint similar to the one
that 
>already exists.  i.e. that suppressing a macro definition causes
undefined 
>behaviour.
>
>I can see why you might want to allow a function call (though it would

>obviously have to be an assembler function that had an intimate
knowledge 
>of how the compiler worked).  But why do it this way?  I'm curious to 
>know why it was done this way, when the standard form of definition, 
>together with a suitable constraint, would have done the job.  It is 
>sufficiently different from all other function/macro descriptions that

>I thought there must be some Machiavellian reason for doing so. :-)
>
>
>-- 
>Ian

  (This is my first posting to a newsgroup, so be gentle...)

 I was a member of X3J11 when we decided this, and my memory was that
we wanted to prevent people from being able to take the address of
setjmp, since many of the implementations couldn't handle something
like:

  int (*funp)();

   ...

   funp = &setjmp;

   ....

   if (funp(jump_buff))
      {
      ...
      }

  Terry.
Technical Details
Message-ID: <47jrmq$du4@ixnews4.ix.netcom.com>
Path: arc1-ca.pugleaf.net!ix.netcom.com!netnews
References: <815241910snz@soliton.demon.co.uk> <478bqi$nb3@rdsunx.crd.ge.com> <815323606snz@soliton.demon.co.uk>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!ix.netcom.com!netnews
From: terrycol@ix.netcom.com (Terry Colligan )
Newsgroups: comp.std.c
Subject: Re: setjmp.h
Date: 6 Nov 1995 02:25:30 GMT
Organization: Netcom
Message-ID: <47jrmq$du4@ixnews4.ix.netcom.com>
References: <815241910snz@soliton.demon.co.uk> <478bqi$nb3@rdsunx.crd.ge.com> <815323606snz@soliton.demon.co.uk>
NNTP-Posting-Host: ix-frm-ma1-20.ix.netcom.com
X-NETCOM-Date: Sun Nov 05  6:25:30 PM PST 1995