On 06/12/2011 15:29, Robert Dewar wrote:
On 12/6/2011 9:16 AM, David Brown wrote:
I would say it's better to have false positives in cases like this, than
false negatives, because there are easy ways to remove the false
positives.
My view is that for compiler warnings, you want to balance false
positives and false negatives. If you give too many false positives
people just turn off the warning anyway. I think the current balance
is probably about right.
I also thought the balance in gcc was quite good, until reading this
thread - without having done any testing myself, it looks like a
regression. gcc 4.0 gave a correct positive warning, while gcc 4.6.1
gave a false negative.
I agree that there's always a balance in cases like this. I just think
the balance has changed for the worse in this case. Whether that's a
fair overall comment or not, I don't know - again, I'm only looking at
the one reported case here.
An earlier post in this thread pointed us to:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501>
An interesting thing to note about that bug is that there are large
number of other bugs that have been consolidated into it as duplicates.
There are also many related issues that have been closed as "won't
fix". This is an indication that this is a topic that many people see
as an issue, and that many people have labelled as a regression. My
guess is that most of the bugzilla filings are from people who have had
mistakes in their code, taken time to find them, then thought "gcc
/used/ to give warnings for such mistakes". In other words, each case
is filed by someone who spend extra time and effort because gcc no
longer warns of these uninitialised uses.
Of course, there is no way to know if there would have been more issues
filed if there were more false positives given.
But clearly the uninitialised warnings are useful, and users would like
to see them improved - if it is possible to do so without adversely
affecting code generation, of course.
If you want more thorough warnings, with no false negatives, then
separate static analysis tools are more appropriate. They can do a
better job than the compiler in any case.
Unfortunately, there are no such tools available that compare with gcc
and its warnings. There are plenty of tools for specific issues, such
as tracking memory leaks. There are also commercial tools - which are
mostly expensive, and give little benefit over gcc's warnings for real
errors (rather than style errors, or coding standard errors) unless you
put a lot of effort into adding specially formatted comments. The
nearest open source tool is splint - it has stagnated for many years,
you need special comments to get much more than the gcc warnings, and it
doesn't support C++.
Every time I have looked at this, I have always come back to gcc as the
best free general-purpose tool for static analysis. I also think it has
the best starting point for such tools - after all, gcc does a great
deal of analysis on the code already, much of which would need
duplicating in a lint program. I don't see any fundamental reason why a
linter could do any better than gcc for such warnings.
To get the most out of a lint program, you need to add a bit to C to
give it extra information - but you already do that with gcc with
attributes. It is far better to give a function a "const" attribute,
and let gcc check that it follows the rules for a "const" function and
also generate better code with that knowledge, than it would be to just
put the "const" information in a special comment for the lint program.
And of course when you use gcc for checking rather than an external
program, it's a natural part of your "make" process and it understands
all gcc-specific features and extensions.
Don't get me wrong here - I understand that making accurate
uninitialised warnings is a hard problem, especially while producing
optimal code, and that it is not likely to be a high priority for the
gcc developers. But I don't think I am alone in saying it is a feature
that gcc users appreciate, that we prefer not to see regressions in such
features, and that we would be very happy to see even more accurate
warnings.
mvh.,
David
