H.J. Lu wrote:
On Sat, Jun 20, 2009 at 6:50 AM, James Dennett<james.denn...@gmail.com> wrote:
I think it is a bad idea to include it in -Wall. You fixed 3 warnings in
gcc and I fixed 1 in binutils. If you have thousands of packages in C,
-Wall may generate hundreds of warnings.
The same is true of any new -Wall warning that applies to existing
code, but we must not let that stop us improving -Wall, even when
existing code generates some (acceptable) level of false positives.
The code is perfectly valid C. This warning provides no additional
useful information which -Wuninitialized doesn't provide.
All warnings are about "perfectly valid C". We give error
messages for anything that is not valid C! Even if you
have a construct that would lead to undefined behavior,
you may still be writing valid C, since you may be sure
this code is never executed. So again, all warnings are
about valid C, and by definition, any new warning will
generate new warnings about valid C.
If people use -Wall, then they must expect more warnings
as -Wall is improved. So to me the backwards compatibility
argument is invalid in this context.
The valid argument is that the warning is not useful,
or generates too many false positives. Note that in this
case a false positive is not about warning when suspicious
useless code did not happen to have any bad consequences.
It is about warning in cases of perfectly reasonable code.
If you have thousands of packages, investigate many false
positive errors may not be feasible on top of many other real
issues in gcc and packages.
But then don't use -Wall. If you are asking for -Wall, you
want all new warnings, and you have to undertake to investigate
them. If you don't want this kind of movement, then specify the
precise warnings you want (even that may generate new warnings
if a given specific warning is improved).
I must say I am really surprised at the claim that this particular
warning will cause lots of new warnings. Do we really have thousands
of packages with this kind of dubious construct?
