I'm pretty sure it's intended, but interestingly, it seems as though the only
way that intent is expressed is through the undefined behavior you get if you
try to use the identifier.
I guess the thing is...
Obviously:
int __func__;
is undefined behavior; you're using a reserved identifier.
But if you do
printf("%s\n", __func__);
I can't tell whether this is a constraint violation, in that you're referring
to an undeclared identifier, or plain undefined behavior, because you're using
a reserved identifier.
... You know, every time I look at this again, my expectation flip-flops. I
conclude that the obvious intent of the standard is that each implementation
shall have a cryptographic-quality source of random numbers, and shall
diagnose this in 50% of all cases, unpredictably.
Perhaps these sections could be relevant to the discussion...
From C89's "COMPLIANCE" section (I believe):
"...A conforming implementation may have extensions (including
additional library functions), provided they do not alter the behavior
of any strictly conforming program..."
Does that suggest that '__func__' could be included in the meaning of
"extensions"? Can a strictly conforming program define '__func__' and
thus have its behaviour altered if the implementation defines it?
From C89's "Predefined macro names" section (I believe):
"...All predefined macro names shall begin with a leading underscore
followed by an upper-case letter or a second underscore..."
From C89's "Standard headers" section (I believe):
"... All other identifiers that begin with an underscore and either
an upper-case letter or another underscore are reserved..."
From C89's "Common extensions" appendix (I believe):
"...The inclusion of any extension that may cause a strictly
conforming program to become invalid renders an implementation
nonconforming. Examples of such extensions are new keywords, or library
functions declared in standard headers or predefined macros with names
that do not begin with an underscore."
Some examples of extensions are then given.
From a foreword associated with C89 (I believe):
"Because external identifiers and some macro names beginning with an
underscore are reserved, implementations may provide special semantics
for such names. For example, the identifier _BUILTIN_abs could be used
to indicate generation of in-line code for the abs function. Thus, the
appropriate header could specify #define abs(x) _BUILTIN_abs(x) for a
compiler whose code generator will accept it. In this manner, a user
desiring to guarantee that a given library function such as abs will be
a genuine function may write #undef abs whether the implementation's
header provides a macro implementation of abs or a builtin
implementation. The prototype for the function, which precedes and is
hidden by any macro definition, is thereby revealed also."
Do these [partial] references suggest that reserved identifiers of the
form '_Xxx' and '__xxx' are free for an implementation to define,
including semantics and behaviour?
Now some GCC documentation which might or might not be relevant:
From GCC 4.3.5's "Extensions to the C Language Family" section (5)[1]:
"...Some features that are in ISO C99 but not C89 or C++ are also, as
extensions, accepted by GCC in C89 mode and in C++..."
From GCC 4.3.5's "Function Names as Strings" section (5.43)[2]:
"...The identifier __func__ is implicitly declared by the translator
as if, immediately following the opening brace of each function
definition, the declaration
static const char __func__[] = "function-name";
appeared, where function-name is the name of the lexically-enclosing
function."
What are your thoughts on the matter, given these?
[1]
http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/C-Extensions.html#C-Extensions
[2]
http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Function-Names.html#Function-Names
