On Fri, Sep 01, 2017 at 11:46:41AM -0600, Jeff Law wrote: > On 08/04/2017 04:04 PM, David Malcolm wrote: > > This patch kit clearly isn't ready yet as-is (see e.g. the > > "known unknowns" below), but I'm posting it now in the hope of > > getting early feedback. > [ ... ] > > > > > > > Statement of the problem > > ======================== > > > > Static analysis is IMHO done too late, if at all: static analysis tools are > > run > > as an optional extra, "on the side", rather than in developers' normal > > workflow, with some kind of "override the compiler and do extra work" hook, > > which may preclude running more than one analyzer at once. Analysis results > > are reviewed (if at all) in some kind of on-the-side tool, rather than when > > the > > code is being edited, or patches being prepared. > I'm sure you know my opinions on this stuff. But for the benefit of the > rest of our readers, I agree, 100% totally on all of this.
I more or less agree, though I think arrangements where its run by build bots and bustage is treated like breaking the build can be reasonable. > For checkers to really be effective, they have to be part of the > standard workflow that we use every day. Anything else is ultimately a > losing battle. That's in large part why I continue to support improving > GCC's ability to emit high quality useful warnings about likely > programming errors. I find myself also wondering how much can be done with generic checkers as opposed to ones specific to a particular project and its style / idioms. if nongeneric checkers are important then it should be important to make it easy for people to write their own checkers. > So this raises one very high level question. By providing this > capability do we undermine further development of GCC's down analysis > capabilities or does it merely allow that development to move to its > most natural place (gcc, llvm/clang, smatch, cppcheck, whatever) > allowing each tool to focus on what it does best? Given there is already a lot of work going on around llvm/clang checkers it seems reasonable to expect there would be less insentive to improve gcc in that area if you could just use the clang based checkers from gcc. Of course if that is a good or bad thing is another question. Most of the static chekers support being invoked on a file or as if they were a compiler. So it should be easy to write a wrapper script that runs the checker and then the compiler if you wishh, or have a build target that does all the static checking. So its not clear to me how much users really get out of this work. In part I wonder if this is more a social problem to solve than a technical one. > > Known unknowns > > ============== > > > > How does one suppress a specific false-positive site? > > Do we need a pragma for it? (though pragmas ought to already affect some of > > the underlying checkers...) > I'm always conflicted on this kind of suppression/marking. You can > easily end up with a boatload of unmaintainable markers. But without > them you've got a firehose of useless information. Sigh. The other question would be if multiple checkers share a false positive, how do you nicely disable all of them. Having 3 different comments / pragmas to disable the same thing sounds unpleasent. thanks Trev
