> On May 25, 2018, at 8:20 AM, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > Btw, on my system the main cause of false positives with that test is > when people mix "if (ret)" and "if (ret < 0)". > > When I run smatch, I rebuild the database every morning. Every time you > rebuild it builds the call tree more and more. So, for most functions, > Smatch eventually figures out all the possible returns and it doesn't > matter if you check for negatives or non-zero. There are still some > functions which Smatch can't figure out, like there is recursion or if > we copy the error code from another thread. I manually hack some of the > most problematic in smatch_data/db/kernel.return_fixes. You mean if you run the rebuild db more than once in a row, the result becomes better what’s the number of times to run to get the best result? Because otherwise I am typically doing a rebuild either once a day or every time after I updated smatch to a newer version (and then compare output of the two versions to see what new it shows/no longer shows to see any problems and to update my “false positives/known bad code we don’t have a fix yet” scripts so it only adds gerrit comments for the new stuff and people don’t get into habit of “oh, those warnings are all useless and not related to my code, it’s ok to just ignore them” -- To unsubscribe from this list: send the line "unsubscribe smatch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
