On Mon, Oct 23, 2023 at 11:18:17AM -0400, Oleg Drokin wrote: > On Mon, 2023-10-23 at 17:08 +0300, Dan Carpenter wrote: > > After we make these two changes the bug is detected. It finds quite > > a > > few bugs that way. The MAYBE_FREED changes generate quite a few > > false > > positives so I haven't decided out how to deal with that yet... > > I think the way to deal with this is "whitelisting"? > For any established project as you introduce new checks, there are > going to be false positives. > You run the check for the first time and (assuming you don't get a > gazillion hits) then separate the results into "valid" and "invalid". > Then the valid ones get patches and invalid ones are marked somehow > (could be coverity-style markup, some external database or I am sure > a number of other methods. For things I care about I keep a local > database I filter things through). > >From then on only new occurrences (result of code changes) will ever > surface and get triaged the same way. And in this case even false > positives might not be as bad. Yeah. You're probably right. I had planned to investigate the warnings and look at various stratagies to silence them on a case by case basis. But a simpler, Big Hammer, approach would be to just create a list of param/key pairs which cancel out a MAYBE_FREE. > If we remember the original coverity paper (that also was when the > original smatch was inspired I think), they have a very astute > observation that "sure, there are false positives, but as we were > investigating them we found other bugs. So if your code is confusing > enough to throw off analysis tools off, it's likely confusing enough to > host bugs of some kind anyway". > Sadly I think the focus shifted a lot since then into "as few of false > positives as possible" and other such pie in the sky matters (not to > say some sort of balance is not important of course). I still write the same code as always, I just tend to not publish it. But it might be fun to just publish everything. A lot of stuff is half finished. I have an idea and test it, but the results are bad and I never make it actually work. Or sometimes I don't know how to make it work but I still leave the code until later. I'm generally bad at pushing code. I write it and then forget about it. :/ The other thing about false positives is that --spammy is supposed to be more false positive prone and --pedantic is used for style issues. The --pedantic option isn't used very much now but in my head maybe it will be in the future. I should probably rename it to --style. One of the bad things about the original Smatch was that I was crap at merging other people's code. These days I tend to merge everything that people send. regards, dan carpenter
