Joerg Sonnenberger wrote in
<[email protected]>:
|Am Fri, Jan 21, 2022 at 12:45:56AM +0100 schrieb Steffen Nurpmeso:
|> Fwiw, i have been astonished by this thread. I found scan-build
|> to generate a lot of false warnings, so much indeed that i stopped
|> using it .. in summer 2017.
|
|I've spend time on the static analyzer output in NetBSD and I wouldn't
|say so much that it creates too many false warnings, but that the pure
Surely i talk only small things.
|text version is not helpful. The HTML output at least explains the
Yes i like that from Coverity you get a text email (or at least
last i used it, development branch in work for two years and that
not yet, and master mostly stable; and the others never, hmm) with
at least the points of interest of all new defects. Most of the
time that is all i need!
|reasoning. From those pre-conditions, it is often easy to deduce why it
|is a false positive from *other* conditions in the program. Properly
|asserting those would certainly improve code.
Like is said somewhen in this thread, you are forced to instrument
code like grazy. And that sucks like grazy; just one or two days
ago, for example, i finally decided to do a FALLTHRU macro and
replace all /* FALLTHRU */ comments with it. One should think
this is a matured thing covered by unit tests on the compiler
front, but i am conservative and just enable it with the compiler
versions i have at hand (working around specific compiler bugs
/ on particular OSs is one of the things), but you stumble
whenever you go! So for gcc 11.2.0 i now have made this
"UNUSED(0);__attribute__ ((fallthrough));" because without the
UNUSED(0); like for clang gcc complains "a label can only be part
of a statement and a declaration is not a statement" in a very
very normal case: fallthrough condition (but only one of the many,
mind you! iirc). Or is "case A:\nFALLTHRU\ncase B:.." forbidden
now too? Honestly i find all these things very much annoying and
not helpful at all. I'd rather have some more keywords like
"unroll" before loop keywords or whatever, so that i have the
control rather than the compiler (i had just read "Who's afraid of
a big bad optimizing compiler?" of LWN some hm week ago).
So this is all theory. Or take this
// xxx clang 5.0.1 BUG: needed this-> to find superclass field
gview(void) {this->csdv_parent = NIL; this->csdv_node = NIL;}
Only there of the many. And whatever. Nono.
|The biggest advantage in coverity is the logic they have for preserving
|the state of analysis across code changes, e.g. once you tag a reported
|issue as analyzed and not a problem, it tries very hard to not show it
|again.
Yes! Even without instrumentation that is.
I mean, hey!, this is _very_ complicated stuff. It is just that
i _never_ had luck with scan-build, really. And the example
i posted last here... Shit always happens, but if you _can_
analyze code execution paths through all units involved in the
run, i would have expected that this condition cannot produce
a false positive, because it cannot. If NIL it jumps away never
to come back. It cannot be NIL in the code that follows, period.
-Weverything is pretty exhaustive, i try to write new code so it
passes this.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
