🚀 go-pugleaf

Ian Cargill <ian@soliton.demon.co.uk> wrote:

>In article <478bqi$nb3@rdsunx.crd.ge.com>
>           volpe@ausable.crd.ge.com "Christopher R. Volpe" writes:
>
>>In article <815241910snz@soliton.demon.co.uk>, Ian Cargill
>> <ian@soliton.demon.co.uk> writes:
>>>
>>>The standard allows setjmp to be either a macro or an 'identifier 
>>>with external linkage'.  Why the latter?   
>>
>>Why not the latter? Why should an implementer be forced to make setjmp a macro
>>rather than an ordinary function call?
>
>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. :-)

Because it may not be possible to implement setjmp as a function.  

Other functions may or may not be implemented as macros, but if they
are macros they must still satisfy the semantics of a function.  For
example, their arguments must be evaluated exactly once and it must be
possible to take their address and pass pointers to them to other
functions.  By defining setjmp as a macro, the implementor is relieved
of having to satisfy these requirements.

Michael M Rubenstein