🚀 go-pugleaf

In article <815323606snz@soliton.demon.co.uk>,
Ian Cargill  <ian@soliton.demon.co.uk> wrote:
>>> The standard allows setjmp to be either a macro or an 'identifier 
>>> with external linkage'.  Why the latter?   
[...]
> 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)  

assert must be a macro, because it can reduce to "(void) 0".

va_start and va_list do non-function-doable things, relying on the
identity of variables, or types, and so on. You've forgotten offsetof,
by the way.

va_end, I believe, could be an ordinary function.

setjmp can be a macro that does magic, or it can be an ordinary
function. Thus the strange words.

> If 7.6.1.1 refered to 'The setjmp function' instead of 'The setjmp macro', 
> 7.1.7 would still permit a macro version.

But this wouldn't allow a macro that doesn't do the same thing as the
function does. The wording of 7.1.7 is to allow "wrapper macros" around
required functions. If setjmp is a macro, then there needn't be a
function at all.

> 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.

And then you would create a different sort of confusion, as to whether
7.1.7 overrides it or not or whatever. The present words seem clear
enough to me.

-- 
Clive D.W. Feather                       | If you lie to the compiler,
clive@demon.net        (work, preferred) | it will get its revenge.
clive@stdc.demon.co.uk (home)            |   - Henry Spencer