bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warning options


From: Paul Eggert
Subject: Re: warning options
Date: Sun, 20 Nov 2011 12:31:19 -0800
User-agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

On 11/20/11 06:58, Bruno Haible wrote:

> And -Wtype-limits warnings in dead code are not useful either:

I agree with you about this one -- it's been a longrunning problem
with GCC.  I use -Wno-type-limits when compiling Emacs.  I have
the problem in non-dead code as well.

> an empty
> function argument list (in a function definition!) is equivalent to (void).

It's not equivalent in C, since (void) gives us extra compile-time type
checking that an empty arglist does not.  For example, there is no
type error (and no GCC diagnostic) in this C code:

  int f () { return 0; }
  int main (void) { return f (1); }

whereas there would be a type error if the () were replaced by (void).
In C, the argument for (void) in particular is similar to the argument
for new-style definitions in general.

> I also won't use -Wunused-macros since it produces warnings that are pointless
> to fix:
> 
> printf-frexp.c:63:0: warning: macro "L_" is not used
> tempname.c:70:0: warning: macro "__open64" is not used
> tempname.c:72:0: warning: macro "__xstat64" is not used
> fnmatch.c:171:0: warning: macro "STRCOLL" is not used
> fnmatch.c:199:0: warning: macro "STRCOLL" is not used
> ...

The first warning I'll grant you (though surely it is easy to work around)
but I don't see why the next four warnings are pointless to fix
(I stopped looking after the fifth warning).
Those macro definitions are never used, so why clutter up the code
with them?

> -Wstrict-overflow give spurious warnings with gcc 4.5:

Yes, -Wstrict-overflow has several problems with older GCCs.
I've been trying to get this fixed by filing bug reports
(e.g., <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48228>).
I don't advocate rewriting the code to pacify older GCC bugs
in this area.  I think Jim works around this problem by using
GCC 4.7 beta; I use 4.6.2.

> Even -Wshadow fires back unreasonably:

This may be taste, but I don't find that warning unreasonable,
as a local (yn) is shadowing a global (yn).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]