On Fri, May 25, 2018 at 07:46:41PM -0400, Oleg Drokin wrote: > > > 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? The results do become better... Say you have code which is inconsistent about "if (ret)" and "if (ret < 0)", then it will complain after the first build. But eventually it will figure out the whole call tree and that none of the functions return positive values so checking for negatives is the same as checking for non-zero. Normally a call chain is 5-7 functions max, but Smatch parses some inline functions without needing the cross function DB so it's figures out the call tree after probably 4 DB rebuilds. > Because otherwise I am typically doing a rebuild either once a day If you're rebuilding the DB once a day, that's what I'm doing too so it should be fine. But really you shouldn't be getting that warning with the latest code at any point I think. Let me know if it still shows up and I'll investigate. regards, dan carpenter -- 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
