On Sat, Aug 01, 2015 at 04:12:20PM +0300, Dan Carpenter wrote: > On Sat, Aug 01, 2015 at 08:22:41PM +0800, Fengguang Wu wrote: > > Hi Dan, > > > > On Fri, Jul 31, 2015 at 05:03:20PM +0300, Dan Carpenter wrote: > > > We're getting a lot of false positives today because the database is > > > out of sync with the kernel we are testing. > > > > Sorry we just fixed a bug that prevented smatch checks for long time. > > So here comes a bunch of smatch reports. > > > > Since the database is expensive to build, we typically reuse the same > > database across a number of kernels, which may lead to the false > > positives you noticed. > > > > I'll try improving the test process. > > > > I understand. I'm not complaining, I'm just explaining why. > > Most of the false positives were things like: > > memset(foo, 0, sizeof(*foo)); > > That should have been fixable on my end. It seemed like a simple thing > and I tried to do that some months back but it just made Smatch segfault > and I was never able to figure it out. I will look again next week. OK, thank you! I just did a patch to force rebuild smatch db on every branch, which would add cost by about 1+ hour. It's reasonably acceptable for me. However it will no longer be a big problem, I can still revert that change. >From my point of view, I'd prefer to make the reports more accurate -- human costs are more valuable than machine costs. What's your opinion? Thanks, Fengguang -- 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
