Hello,
Modern C standard (C99) defines __FUNCTION__ as if immediately after
function open brace string with function name is declared. Thus, it's
invalid to use string concatenations like __FILE__ ":" __FUNCTION__.
Gcc 3.03 gives warning for such use of __FUNCTION__. Before this
warnings become error, it's worth to fix this in the kernel source.
I found tons of improper __FUNCTION__ usage in USB drivers. I am not to
say, USB is the only place, I just started with it. In USB, typical use
is with dbg() and alike macros. dbg() defined in usb.h as follows:
#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format "\n"
, ## arg)
In source it is usually used like
dbg(__FUNCTION__ " endpoint %d\n", usb_pipeendpoint(this_urb->pipe));
I propose modification for dbg() and friends like
#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ":%s - " format
"\n", __FUNCTION__, ## arg)
This will enable the same usage, but will incorporate __FUNCTION__ in
the common message prefix. This centralization will force function name
in all messages, and make it easy to fix code. Code will be shorter and
cleaner. It may be worth to (#ifdef MODULE) add module name to message
prefix.
Any comments?
Please, when replying, CC me: mailto:[email protected]
Vladimir Kondratiev wrote:
> Hello,
> Modern C standard (C99) defines __FUNCTION__ as if immediately after
> function open brace string with function name is declared. Thus, it's
> invalid to use string concatenations like __FILE__ ":" __FUNCTION__.
>
> Gcc 3.03 gives warning for such use of __FUNCTION__. Before this
> warnings become error, it's worth to fix this in the kernel source.
>
> I found tons of improper __FUNCTION__ usage in USB drivers. I am not
> to say, USB is the only place, I just started with it. In USB, typical
> use is with dbg() and alike macros. dbg() defined in usb.h as follows:
>
> #define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format
> "\n" , ## arg)
>
> In source it is usually used like
>
> dbg(__FUNCTION__ " endpoint %d\n", usb_pipeendpoint(this_urb->pipe));
>
> I propose modification for dbg() and friends like
>
> #define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ":%s - " format
> "\n", __FUNCTION__, ## arg)
>
> This will enable the same usage, but will incorporate __FUNCTION__ in
> the common message prefix. This centralization will force function
> name in all messages, and make it easy to fix code. Code will be
> shorter and cleaner. It may be worth to (#ifdef MODULE) add module
> name to message prefix.
>
> Any comments?
I suspect this might be about as religious an issue as there is but has
anyone thought about coming up with some "standard" debugging macros,
perhaps something that can be configured at compile time from the
configuration for everyone to use everywhere? I've got my own debug
macros, essentially a printk with the file, function and line added
wrapped in #ifdef DEBUG. I've seen several other schemes in other parts
of the kernel and now some of them aren't correct.
I guess what I would envision is some kind of debug menu item in the
configuration tool that let's you select if you want messages, and/or
filenames, and/or line numbers, and/or function names, or nothing at
all. They could still be controlled at the module level by defining or
not defining some constant. It just seems kind of pointless to have
10-20 different macros or methods that all do the same thing for
different parts of the kernel.
Ian
--
Ian S. Nelson <[email protected]> 303-666-0315
Nelson Computing of Boulder Colorado
Networking/Contracting/Custom Software/Linux Fast and Personal service
On Tue, Jan 08, 2002 at 11:36:11PM +0200, Vladimir Kondratiev wrote:
> Hello,
> Modern C standard (C99) defines __FUNCTION__ as if immediately after
> function open brace string with function name is declared. Thus, it's
> invalid to use string concatenations like __FILE__ ":" __FUNCTION__.
Hi,
Can you point me to the place in the spec this is defined? I don't see
__FUNCTION__ defined anywhere in the ISO/IEC 9899:1999 (the official C99)
specification.
thanks,
greg k-h
On Tue, Jan 08, 2002 at 02:59:46PM -0700, Ian S. Nelson wrote:
>
> I suspect this might be about as religious an issue as there is but has
> anyone thought about coming up with some "standard" debugging macros,
> perhaps something that can be configured at compile time from the
> configuration for everyone to use everywhere? I've got my own debug
> macros, essentially a printk with the file, function and line added
> wrapped in #ifdef DEBUG. I've seen several other schemes in other parts
> of the kernel and now some of them aren't correct.
Jeff Garzik and others have talked about unifying the network driver's
debug statements and levels with a common set of macros and level
values. I want to do the same thing with the USB drivers, but was
waiting for them to finalize their scheme first (and hopefully use the
same thing.)
So yes, I think there can be some kind of "standard" debugging macros,
but the "standard" will probably be limited to a subset of the kernel.
greg k-h
On Tue, Jan 08, 2002 at 02:01:50PM -0800, Greg KH wrote:
>
> Can you point me to the place in the spec this is defined? I don't see
> __FUNCTION__ defined anywhere in the ISO/IEC 9899:1999 (the official C99)
> specification.
Don't have a C99 spec, but here's what info gcc has to say about it:
[...description of "function names" extension as currently found in gcc...]
Note that these semantics are deprecated, and that GCC 3.2 will
handle `__FUNCTION__' and `__PRETTY_FUNCTION__' the same way as
`__func__'. `__func__' is defined by the ISO standard C99:
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.
Jeroen
Ian S. Nelson wrote:
> I suspect this might be about as religious an issue as there is but
> has anyone thought about coming up with some "standard" debugging
> macros, perhaps something that can be configured at compile time from
> the configuration for everyone to use everywhere? I've got my own
> debug macros, essentially a printk with the file, function and line
> added wrapped in #ifdef DEBUG. I've seen several other schemes in
> other parts of the kernel and now some of them aren't correct.
>
> I guess what I would envision is some kind of debug menu item in the
> configuration tool that let's you select if you want messages, and/or
> filenames, and/or line numbers, and/or function names, or nothing at
> all. They could still be controlled at the module level by defining
> or not defining some constant. It just seems kind of pointless to
> have 10-20 different macros or methods that all do the same thing for
> different parts of the kernel.
> Ian
>
I am fully agree with idea of one set of debug/info/warn/etc. macros.
My main point in prev. posting was to fix __FUNCTION__, for USB this
seems to be easy doable since there is already subsystem-wide dbg() and
alike macros. Actually, there is no sense for __FUNCTION__ to appear
outside macros; in real code it provides no added value (except easy
cut-n-paste from function to function).
On Tue, Jan 08, 2002 at 11:56:49PM +0100, jtv wrote:
>
> Don't have a C99 spec, but here's what info gcc has to say about it:
>
> [...description of "function names" extension as currently found in gcc...]
>
> Note that these semantics are deprecated, and that GCC 3.2 will
> handle `__FUNCTION__' and `__PRETTY_FUNCTION__' the same way as
> `__func__'. `__func__' is defined by the ISO standard C99:
Any reason _why_ they would want to break tons of existing code in this
manner? Just the fact that the __func__ symbol is there to use?
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?
greg k-h
On Tue, Jan 08, 2002 at 03:11:47PM -0800, Greg KH wrote:
> On Tue, Jan 08, 2002 at 11:56:49PM +0100, jtv wrote:
> >
> > Don't have a C99 spec, but here's what info gcc has to say about it:
> >
> > [...description of "function names" extension as currently found in gcc...]
> >
> > Note that these semantics are deprecated, and that GCC 3.2 will
> > handle `__FUNCTION__' and `__PRETTY_FUNCTION__' the same way as
> > `__func__'. `__func__' is defined by the ISO standard C99:
>
> Any reason _why_ they would want to break tons of existing code in this
> manner? Just the fact that the __func__ symbol is there to use?
>
> 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.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Tue, Jan 08, 2002 at 03:11:47PM -0800, Greg KH wrote:
>
> Any reason _why_ they would want to break tons of existing code in this
> manner? Just the fact that the __func__ symbol is there to use?
At a guess, it probably gives the gcc folks some more leeway as to where
they implement the feature relative to string constant concatenation and
such. If that is indeed the case, it could lead to cleaner code.
> 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.
I'm pretty sure it's got to be in there somewhere--it was in the summary I
read at the time. :)
Jeroen
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.
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
in and changing the code is clearly not an option. The only options
are to:
1: Not use the newer compiler
2: Grotty sed script to gobble the warnings
3: Fix the compiler.
I've done all three :(
-
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
or
b.) Had a lot of bugs in your code that gcc didn't warn about before
In both cases I'd recommend fixing the code...
> 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.
Regards: David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
David Weinehall wrote:
>
> > 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.
>
When, and whether to do that should be my choice.
(And as the code in question was handling an entire
nation's 1-800 traffic, we stuck with the old compiler,
ta very much).
-
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/
On Tue, Jan 08, 2002 at 03:11:47PM -0800, Greg KH wrote:
> Any reason _why_ they would want to break tons of existing code in this
> manner?
__FUNCTION__ was never a string literal in g++ because you can't decide
what the name of a template is until you instantiate it.
Having __FUNCTION__ be a magic cpp thingy means there is a translation
phase violation. Preprocessor macros are expanded in phase 4, string
concatenation happens in phase 6, syntactic and symantic analysis
doesn't happen until phase 7.
So changing this allows us to change two things: (1) the integrated
preprocessor can concatenate adjacent string literals and do lexical
analysis exactly as described in the standard, and (2) removes an
irrelevant difference between c and c++ so that at some point we can
support both with a single front-end.
r~
On Tue, Jan 08, 2002 at 06:12:02PM -0800, Richard Henderson wrote:
>
> __FUNCTION__ was never a string literal in g++ because you can't decide
> what the name of a template is until you instantiate it.
According to the info page it was:
The compiler automagically replaces the identifiers with a
string literal containing the appropriate name.
This is written right after a lovely C++ example of using __FUNCTION__
and __PRETTY_FUNCTION__. But I can understand the difficulties of
determining this for some C++ cases.
> Having __FUNCTION__ be a magic cpp thingy means there is a translation
> phase violation. Preprocessor macros are expanded in phase 4, string
> concatenation happens in phase 6, syntactic and symantic analysis
> doesn't happen until phase 7.
>
> So changing this allows us to change two things: (1) the integrated
> preprocessor can concatenate adjacent string literals and do lexical
> analysis exactly as described in the standard, and (2) removes an
> irrelevant difference between c and c++ so that at some point we can
> support both with a single front-end.
So, if you are going to change this (well, sounds like it is already
done), what is the timeline from taking a well documented feature and
breaking it (based on the example in the info page)? First a warning,
and then an error, right? What version of the compiler emits a warning,
and what future version will emit an error? I didn't see anything about
these kinds of changes in the gcc development plan, or am I missing some
documentation somewhere?
thanks,
greg k-h
Greg KH wrote:-
> So, if you are going to change this (well, sounds like it is already
> done), what is the timeline from taking a well documented feature and
> breaking it (based on the example in the info page)? First a warning,
> and then an error, right? What version of the compiler emits a warning,
> and what future version will emit an error? I didn't see anything about
> these kinds of changes in the gcc development plan, or am I missing some
> documentation somewhere?
The documentation snippet someone posted said it would be removed in 3.2.
3.0.3 emits the warning, as does 3.1 in CVS.
Neil.
Greg KH wrote:
>On Tue, Jan 08, 2002 at 11:56:49PM +0100, jtv wrote:
>
>>Don't have a C99 spec, but here's what info gcc has to say about it:
>>
>>[...description of "function names" extension as currently found in gcc...]
>>
>> Note that these semantics are deprecated, and that GCC 3.2 will
>>handle `__FUNCTION__' and `__PRETTY_FUNCTION__' the same way as
>>`__func__'. `__func__' is defined by the ISO standard C99:
>>
>
>Any reason _why_ they would want to break tons of existing code in this
>manner? Just the fact that the __func__ symbol is there to use?
>
String constant coalescing chances. It is a good thing. Anobody who used
__FUNCTION__ which was
neither a proper preprocessor constant nor a proper variable
semantically was in problem.
On Tue, Jan 08, 2002 at 11:23:13PM -0800, Greg KH wrote:
> On Tue, Jan 08, 2002 at 06:12:02PM -0800, Richard Henderson wrote:
> > __FUNCTION__ was never a string literal in g++ because you can't decide
> > what the name of a template is until you instantiate it.
>
> According to the info page it was:
> The compiler automagically replaces the identifiers with a
> string literal containing the appropriate name.
The info page lied. This was true for C, but not C++.
> So, if you are going to change this (well, sounds like it is already
> done),
No, not done yet. Just warning now -- the feature still works (in C).
> what is the timeline from taking a well documented feature and
> breaking it (based on the example in the info page)? First a warning,
> and then an error, right?
Correct. The first gcc version to warn is 3.0.3, released Dec 20, 2001,
The feature will be removed in 3.2, due Oct 15, 2002 if everything goes
according to schedule.
r~