🚀 go-pugleaf

In article <815323606snz@soliton.demon.co.uk>, Ian Cargill <ian@soliton.demon.co.uk> writes:
|> 
|> 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)  

Because most functions can be used either as a macro or as a function, at
the PROGRAMMER's choice.  setjmp() can be one or the other, but at the
IMPLEMENTOR'S choice - the programmer has no say.

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

This exists for only a few functions, but you are correct that this
wording could have been used.

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

Firstly, it does NOT have to have an intimate knowledge of how the compiler
works - all it needs to know is the inter-function calling conventions
and possibly how the stack is linked.

Secondly, <assert.h>, <stdarg.h> and <setjmp.h> are unusual in that they
define constructions that are sometimes handled by the compiler and
sometimes by the run-time system.  And this is always the implementor's
choice and never the programmer's.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679