On Tue, Feb 23, 2016 at 05:45:55PM +0000, Kershner, David A wrote: > > > > -----Original Message----- > > From: Dan Carpenter [mailto:dan.carpenter@xxxxxxxxxx] > > Sent: Friday, February 12, 2016 5:02 PM > > To: Romer, Benjamin M <Benjamin.Romer@xxxxxxxxxx> > > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; driverdev-devel@xxxxxxxxxxxxxxxxxxxxxx; > > Sell, Timothy C <Timothy.Sell@xxxxxxxxxx>; *S-Par-Maintainer > > <SParMaintainer@xxxxxxxxxx> > > Subject: Re: Time for a code audit? > > > > I looked at the Smatch warnings, plus some bonus stuff I'm still working > > on. > > > > drivers/staging/unisys/include/iochannel.h:592 add_physinfo_entries() > > warn: inconsistent indenting > > drivers/staging/unisys/include/iochannel.h:596 add_physinfo_entries() > > warn: inconsistent indenting > > drivers/staging/unisys/include/iochannel.h:600 add_physinfo_entries() > > warn: XXX should 'inp_pfn + i' be a 64 bit type? > > > > This is because the left side is u64 but we wrap at u32. > > > > Dan, thanks for the find. Though I'm curious what options are you using when you run smatch to produce the "warn: XXX should 'inp_pfn +I' be a 64 bit type" message? When I run smatch locally I don't see that message but I see the other two and it is definitely a problem in the codebase that I'm looking at. > These are things I'm still working on and haven't published yet. It feels like it should be a warning though. I'm not certain the heuristic to use here. Sometimes people declare things as u64 when they don't care. Also Smatch tries to be clever about if the integer overflow is actually possible but sometimes it still gets false positives. regards, dan carpenter _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
