Status of gcc __FUNCTION__ crippling

[Niels Möller]

Hi, I've tried to look up the current status of the gcc __FUNCTION__
extension. From the gcc-3.3.2 manual, it seems that string catenation
with __FUNCTION__ is still deprecated, but not yet removed. Perhaps
it's still a chance to reverse the decision to remove this feature?

I'm Cc:ing rms, because I think that perhaps you'd object to the
decision to gratiously remove a useful and widely used feature from an
important GNU program).

I use __FUNCTIOM__ mainly for debugging information, like

  #if DEBUG
  #define DEBUG_CTX (__FILE__ ":" STRINGIZE(__LINE__) ": " __FUNCTION__)
  void *foo_alloc_debug(size_t size, char *ctx);
  #define foo_alloc(size) foo_alloc_debug(size, DEBUG_CTX)
  #else
  void *foo_alloc(size_t size);
  #else

Getting a statically allocated thing that describes location and
function is essential (I wouldn't want dynamic allocation for this).
Having a plain char* to pass around is also very convenient. I think
this usage is fairly typical, and quite common in C programs that use
gcc extensions at all. __func__ is no substitute for __FUNCTION__ as
__func__ is a variable, not a string literal.

This is a gcc extension I've been using for years, and I'm also the
guy who, after a short discussion about it on the gcc-bugs list in
October 1999, contributed the paragraph of the gcc manual which claim
that string catenation on __FUNCTION__ works.

:    The compiler automagically replaces the identifiers with a string
: literal containing the appropriate name. Thus, they are neither
: preprocessor macros, like `__FILE__' and `__LINE__', nor variables.
: This means that they catenate with other string literals, and that
: they can be used to initialize char arrays. For example
: 
:      char here[] = "Function " __FUNCTION__ " in " __FILE__;

I've seen two main arguments for removing/crippling __FUNCTION__:

1. It doesn't work in current C++, in particular with templates.
2. It looks like a preprocessor macro, although it isn't one.

Lets start with (2): This has worked in practice for years, with both
the old (cccp) and the new (cpplib) preprocessors, and as far as I
understand, it's fairly simple on the implementation side (I'm talking
about C now). The macro-like name may be a little confusing for people
who try to use this extension without reading the manual, but that's
true for most features a C programmer use. I think naming is an issue
that should be orthogonal to the discussion about the properties of
__FUNCTION__. If the name is a problem, it could be renaming it to
__gcc_function__ or something, I would much prefer that to crippling
of the __FUNCTION__ functionality.

As for (1), I don't think a C++ problem is a good reason to cripple
the C compiler. I shouldn't speak for C++ folks, but if __FUNCTION__
can't work in C++, or *has* to be implemented as an alias of the
standard __func__, then I guess it makes sense to deprecate
__FUNCTION__ completely for C++ (i.e. *remove* it completely in a few
years, not just change its behaviour).

If you remove the good old gcc extension __FUNCTION__, or (as is the
case when catenation is deprecated) change it in incompatible ways,
which gcc extension will be removed or crippled next? Should I stop
using all gcc extensions immediately, if I want to be compatible with
the next gcc version?

Best regards,
/Niels Möller