[...]
I think the idea is that an implementation isn't allowed to quietly
ignore other characters in those contexts, which would be allowed if
the behavior were undefined. For example, an implementation may
permit additional implementation-defined characters in identifiers
('$' is not uncommon); if it does so, it must treat the identifiers xy
and x$y as distinct. Similarly, if you have an '@' character in a
string literal, the compiler must either accept it (after the
source-to-execution conversion in translation phase 5) or issue a
diagnostic.
Hmm, I just tried to use '$' in both an identifier declaration and a
character constant and gcc didn't complain.
It doesn't have to complain for a character constant but it's
undefined behavior. If you use it as an identifier the compiler must
provide at least a warning.
Using '$' in a character constant is perfectly well defined if '$' is
part of the implementation's extended character set, which in the case
of gcc it surely is.
No diagnostic is required for an identifier with a '$' in it if the
implementation supports it. C99 6.4.2.1 defines the syntax of an
identifier; it includes "other implementation-defined character" as
one of the possibilities for "identifier-nondigit". Paragraph 3 says:
An implementation may allow multibyte characters that are not part
of the basic source character set to appear in identifiers; which
characters and their correspondence to universal character names
is implementation-defined.
This is a change from C90. In C90, the only characters allowed in
identifiers are uppercase and lowercase letters, digits, and
underscore. A C90 implementation may permit other characters as an
extension, but it must still issue the required diagnostic for the
syntax error.
Allowing '$' in identifiers is an extension (in the sense of C90 4p2)
for C90, but is merely an implementation-defined feature in C99. So
producing a diagnostic in C90 mode but not in C99 mode is actually
correct. (Of course, producing a diagnostic in C99 mode would also be
correct, but it's not required.)
If gcc does this (Bacarisse has verified this in another post and then
I tested it too), then it's not compliant, because it does not provide
a diagnostic for the constraint violation. You can complain if you
care enough - I don't. But it's not really wrong, because simply gcc
never claimed C99 compliance, and that is not what the -std=c99 option
currently does.
<OT>
If this were a failure to diagnose a C99 constraint violation,
then it would certainly be worth complaining about. The goal of
"gcc -std=c99" is to support the C99 standard; the gcc folks know
they're not there yet, but they do want to document any shortcomings
at <
http://gcc.gnu.org/c99status.html>.
gcc is free to accept @ as a character constant, but it's undefined
behavior too (like $). As for using it in identifiers - it simply is
not an extension supported by gcc. ($ in identifiers is an extension)
Because it is a constraint violation, the diagnostic is provided as
required, at least when invoked in compliance mode.
As with '$', '@' in a character constant is ok (though strictly
non-portable), but you can't use '@' in an identifier. Attempting to
do so yields a syntax error. For example this:
int foo@bar;
becomes this sequence of preprocessing tokens:
int foo @ bar ;
and since the @ preprocessing token cannot be converted to a token,
this violates the constraint in 6.4p2. If gcc permitted '@ in
identifiers (either as an extension in C90 or as an "other
implementation-defined character" in C99), the sequence of
preprocessing tokens would be
int foo@bar ;
