Messages in this thread | | | Date | Wed, 09 Jan 2002 00:23:09 +0000 | From | Anton Altaparmakov <> | Subject | Re: __FUNCTION__ |
| |
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...
-- "I've not lost my mind. It's backed up on tape somewhere." - Unknown -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |