So, 234i is not C, "int __attribute__((something)) something;"
isn't C either, both are invalid according to the grammar.
The former is not magical, the latter is. Does "reserved" really
clearly imply this magic/not-magic distinction?
It is not the "reserved" per se, but rather the fact that use
of a reserved identifer results in undefined behavior.
In my C99 draft, this is in section 7.1.3, "Reserved identifiers",
where we have the following text:
...
- 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 that is reserved in that
context (other than as allowed by 7.1.8), the behavior is
undefined.134
(Note that you must add more C99 text before interpreting the above
too literally, since (e.g.) __func__ fits this pattern, but has
Standard-defined semantics, so a C programmer can use __func__ in
the Standard-defined way without losing all of the other C99
guarantees.)
(Note also that the text above says "declares or defines", so one
might attempt to call gcc non-conformant at this point, since "int
__attribute__" is not yet a complete definition: we would have to
see a semicolon, comma, or equal-sign-and-expression in order to
get the definition to happen. Perhaps simpler, we could point to
gcc's __extension__, which gcc allows to appear in a context that
does not even *resemble* a declaration or definition. I would
argue, though, that the draft wording I quoted above fails to
capture the "true intent" of the Standard, which allows the compiler
to "pre-define" any reserved identifier. Perhaps, for instance,
the preprocessor starts out by doing "#define __extension__" in
such a way that the occurrence of __extension__ declares a second
reserved identifier, thus triggering the undefined behavior. [This
is not in fact what gcc does, but we cannot observe this fact with
any strictly conforming code -- even "#ifdef __extension__" is not
sufficient, since gcc *could* #define __extension__ only on those
source lines where there are no "#ifdef" tests for it -- so from
a black-box point of view, at least, gcc can get away with this.])
(If the goal is to find "gcc bugs", it is simpler to find "real"
failures in gcc's conformance, in which compiling with -std=c99
fails to implement C99 in various ways. There may well be various
conformance bugs with -std=c89 aka -ansi as well. And of course
gcc obviously fails to conform with "-ansi" unless one *also*
includes "-pedantic", since "-ansi", by design, does not turn on
all the required diagnostics. But this little aside is not relevant
to my rela point, which is: compilers are allowed, and even
encouraged, to use Standard C's "undefined behavior" in various
well-controlled, documented-in-the-implementation-manual ways to
provide features that are otherwise missing from Standard C, so
that real programmers can get real work done.)