Re: Bug in manual for gcc-2.95: __FUNCTION__

[nisse at lysator dot liu dot se (Niels Möller)]

Ok, here is a patch to gcc/extend.texi from gcc-2.95.1. It also contains a
short quote from the draft standard (as I found it on the net; I don't
have any authoritative copy). I hope that is fair use, the
ISO-standard most likely being copyrighted with all rights reserved.

Regards,
/Niels

-----8<-------
520 sanna $ diff -u extend.texi-original extend.texi
--- extend.texi-original	Wed Apr 14 07:34:34 1999
+++ extend.texi	Tue Oct 12 20:54:21 1999
@@ -2953,10 +2953,11 @@
 @node Function Names
 @section Function Names as Strings
 
-GNU CC predefines two string variables to be the name of the current function.
-The variable @code{__FUNCTION__} is the name of the function as it appears
-in the source.  The variable @code{__PRETTY_FUNCTION__} is the name of
-the function pretty printed in a language specific fashion.
+GNU CC predefines two magic identifiers to hold the name of the current
+function. The identifier @code{__FUNCTION__} holds the name of the function
+as it appears in the source. The identifier @code{__PRETTY_FUNCTION__}
+holds the name of the function pretty printed in a language specific
+fashion.
 
 These names are always the same in a C function, but in a C++ function
 they may be different.  For example, this program:
@@ -2992,10 +2993,40 @@
 __PRETTY_FUNCTION__ = int  a::sub (int)
 @end smallexample
 
-These names are not macros: they are predefined string variables.
-For example, @samp{#ifdef __FUNCTION__} does not have any special
+The compiler automagically replaces the identifiers with a string
+literal containing the appropriate name. Thus, they are neither
+preprocessor macros, like @code{__FILE__} and @code{__LINE__}, nor
+variables. This means that they catenate with other string literals, and
+that they can be used to initialize char arrays. For example
+
+@smallexample
+char here[] = "Function " __FUNCTION__ " in " __FILE__;
+@end smallexample
+
+On the other hand, @samp{#ifdef __FUNCTION__} does not have any special
 meaning inside a function, since the preprocessor does not do anything
 special with the identifier @code{__FUNCTION__}.
+
+GNU CC also supports the magic word @code{__func__}, defined by the
+draft standard for C-99:
+
+@display
+The identifier @code{__func__} is implicitly declared by the translator
+as if, immediately following the opening brace of each function
+definition, the declaration
+
+@smallexample
+static const char __func__[] = "function-name";
+@end smallexample
+
+appeared, where function-name is the name of the lexically-enclosing
+function. This name is the unadorned name of the function.
+@end display
+
+By this definition, @code{__func__} is a variable, not a string literal.
+In particular, @code{__func__} does not catenate with other string
+literals.
+
 
 @node Return Address
 @section Getting the Return or Frame Address of a Function
----8<---

Previous message, included for reference:

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

> > So I'd like to propose that
> > 
> > (i) Information about the type and storage class of __FUNCTION__ be
> >     added to the manual.
> > (ii) If for some reason that is not already the case, the type and
> >      storage class be changed to static const char *.
> 
> I agree the documentation could be more clear, but I believe these
> things work differently than you think they work. __FUNCTION__ is most
> similar to a string *literal*. I.e you can do things like
> 
> char *World()
> {
>   return "Hello," __FUNCTION__;
> }
> 
> and it will return (a pointer to) the string "Hello,World". What type
> this thing has depends on the language; in C, it is different than in
> C++.
> 
> Is this information satisfactory? If so, could you provide a patch to
> the documentation? With your own words, you'd be sure that the
> documentation covers the information you think it should cover.
> 
> Please send the patch to gcc-patches@gcc.gnu.org.
> 
> Also note that gcc (now) supports the __func__ construct, as defined
> in C9X. Please look at the (draft?) C99 standard how this ought to
> work.
> 
> Thanks,
> Martin