Re: alloca again

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> #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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B