>>> #if defined(_NETBSD_SOURCE)
>>> #if defined(alloca) && (alloca == __builtin_alloca) && \
>> [...]
> _NETBSD_SOURCE and __builtin_alloca are each in reserved-for-any-use
> namespace, so there are no grounds for citing the standard as basis
> for any behaviour whatsoever from that.
I think I overstated the case. Those two _are_ reserved, but I think
testing them in the preprocessor like that does not produce undefined
behaviour. (Quotes below.)
I think it would be conformant for __builtin_alloca to expand to, for
example, the four tokens & < % 14. Presumably this would be done only
when the compiler in question accepts that, but even then I think there
is no requirement that compiler accept that as part of a *preprocessor*
expression.
Of course, this is not to say that the test quoted is a bad thing, only
that it is nonportable - but nonportability is not necessarily a bad
thing in implementation-specific places (such as system headers). It
*does*, however, mean that citing the standard as basis for expecting
any particular behaviour is unjustified.
Here are relevant quotes I've found:
7.1.3 Reserved identifiers
[#1] [...]
-- All identifiers that begin with an underscore and
either an uppercase letter or another underscore are
always reserved for any use.
[...]
[#2] No other identifiers are reserved. If the program
declares or defines an identifier in a context in which it
is reserved (other than as allowed by 7.1.4), or defines a
reserved identifier as a macro name, the behavior is
undefined.
I have not found any grounds for thinking that doing anything else with
reserved identifiers, such as the preprocessor test at hand, produces
undefined behaviour. It appears to be only declaring, defining, or
undefining reserved identifiers that provokes undefined behaviour (and
undefining, only when there is something to undefine). Undefining is
not mentioned in 7.1.3 [#2]; that is in 7.1.3 [#3]
[#3] If the program removes (with #undef) any macro
definition of an identifier in the first group listed above,
the behavior is undefined.
(The "first group" is the "All identifiers that begin..." quoted
above.) These are also mentioned in the list of things provoking
undefined behaviour in J.2:
-- The program declares or defines a reserved identifier,
other than as allowed by 7.1.4 (7.1.3).
-- The program removes the definition of a macro whose
name begins with an underscore and either an uppercase
letter or another underscore (7.1.3).
(7.1.4 talks about standard-specified library functions.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
