Re: __FUNCTION__

[Anton Altaparmakov]

At 00:04 09/01/02, David Weinehall wrote:
>On Tue, Jan 08, 2002 at 03:51:02PM -0800, Andrew Morton wrote:
> > David Weinehall wrote:
> > > ...
> > > > Since the C99 spec does not state anything about __FUNCTION__, changing
> > > > it from the current behavior does not seem like a wise thing to do.
> > > >
> > > > Any pointers to someone to complain to, or is there no chance for
> > > > reversal?
> > >
> > > Because the want people to stop using a gcc-specific way and start
> > > using the C99-mandated way instead?! Very sane imho.
> > >
> > They shouldn't take a GNU extension which has been offered
> > for ten years and suddenly revert it, or unoptionally spit a
> > warning.  But they keep on doing this.
>
>Well, as the C standards evolve to incorporate things that gcc earlier
>had to create extensions to provide, it is reasonable that gcc, which
>after all _is_ a C-compiler (yeah, yeah, I know that gcc is GNU Compiler
>Collection or whatever, but disregard from that now, ok?!) should
>use those. Deprecating the use of the extension in one release and
>removing it from the next is something we do from time to time in the
>kernel too...
>
> > I've had large codebases which compiled just fine five years ago.
> > But with a current compiler, same codebase produces an *enormous*
> > number of warnings.  There's no switch to turn them off and going
>
>So, you:
>
>a.) Coded with a lot of gcc specific code
>[snip]
>In both cases I'd recommend fixing the code...

Why? Using a perfectly well documented extension is certainly not wrong. Or 
are you saying one shouldn't use gcc extensions?!? We should rewrite half 
the kernel then...

> > in and changing the code is clearly not an option.  The only options
>
>Huh? Most likely, your code is broken, rather than blaming the
>messenger, act properly upon the received message.

His code is not broken at all. gcc has just turned on its head. I 
absolutely agree with Andrew here that gcc shouldn't do that.

The gcc-2.96 manual which I just looked up explicitly says for __FUNCTION__:
---quote---
  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__;
---quota---

So now they are suddenly saying "sorry we are changing how __FUNCTION__ 
works" which is ridiculous IMO.

What is wrong with keeping __FUNCTION__ as it is?!?

Note that gcc-2.96 also supports __func__ and that has the C-99 defined 
semantics so clearly both can co-exist without a problem... Again from the 
gcc-2.96 manual:

  GNU CC also supports the magic word `__func__', defined by the ISO
standard C-99:

---quote---
      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. This name is the unadorned name of the function.

    By this definition, `__func__' is a variable, not a string literal.
In particular, `__func__' does not catenate with other string literals.
---quote---

Taking functionality away like this seems to me (never even seen the gcc 
source) very silly.

Best regards,

         Anton

ps. Yeah, I know gcc-2.96 is not an official gcc release but I don't care. 
It works and it's the only compiler I have here to look the docs up for...