From: Philip Oakley Date: Tue, 16 Jul 2013 22:18:57 GMT Subject: Re: [PATCH] Fix some sparse warnings Message-ID: <51E5C6D1.7000505@iee.org> In-Reply-To: <51E5B8BD.8090202@googlemail.com> On 16/07/13 22:18, Stefan Beller wrote: > On 07/16/2013 10:53 PM, Philip Oakley wrote: >> From: "Jeff King" >> Sent: Tuesday, July 16, 2013 7:21 AM >>> On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote: >>> >>>> Am 7/15/2013 19:31, schrieb Ramsay Jones: >>>>> Sparse issues three "Using plain integer as NULL pointer" warnings. >>>>> Each warning relates to the use of an '{0}' initialiser expression >>>>> in the declaration of an 'struct object_info'. >>>> >>>> I question the value of this warning. Initialization with '= {0}' is >>>> a >>>> well-established idiom, and sparse should know about it. Also, plain >>>> 0 >>>> *is* a null pointer constant. >>> >>> I agree with you. It's not a bug, and I think sparse is being overly >>> picky here; it is missing the forest for the trees in interpreting the >>> idiom. >>> >>> Still, it may be worth tweaking in the name of eliminating compiler >>> noise, since it does not cost us very much to do so (and I believe we >>> have done so in the past, too). >>> >>> We could also ask people with sparse to turn off the "use NULL instead >>> of 0" warning, but I think it _is_ a useful warning elsewhere (even >>> though it is never a bug, it violates our style guidelines and may be >>> an >>> indication of a bug). It would be nice if sparse learned to ignore the >>> warning in this particular idiom, but I am not going to hold my breath >>> for that. >>> >>> -Peff >>> -- >> >> On the subject of warnings and null pointers, yesterday's Code Project >> news linked to a blog on the problems of unexpected optimization bugs, >> such as dereferencing a null pointer. "Finding Undefined Behavior Bugs >> by Finding Dead Code" http://blog.regehr.org/archives/970 which links to >> the draft of an interesting paper >> [http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf] >> >> Does anyone run the "new static checker called 'Stack' that precisely >> identifies unstable code"? [though the paper's conclusion says 'All >> Stack source code will be publicly available.' which suggests it's not >> yet available] >> >> Or use the ‘-fno-delete-null-pointer-checks’ referred to in the blog >> comments (see also index : kernel/git/torvalds/linux.git "Add >> '-fno-delete-null-pointer-checks' to gcc CFLAGS" >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a3ca86aea507904148870946d599e07a340b39bf >> >> >> You're probably already aware of these aspects but I thought it worth >> mentioning for the wider readership. >> >> regards >> >> Philip >> >> > > I recently started contributing and I used cppcheck found at > https://github.com/danmar/cppcheck to submit the patches > at origin/sb/misc-fixes > As it is originally for C++, that tool throws lots of > false-positives (i.e. warns about null pointer dereferencing > when it's not possible to be a null pointer) unfortunately. > > Also I hear llvm/clang comes with a good static code analyzer, > which I tried today on a different project. > Though I could not figure out how to use that on a pure C project > such as git, as that tool seems to require a C++ compilation for > doing its static code analysis. > > The blog post you linked to seems very interesting and promising. :) > > Regards, > Stefan > A bit more searching also finds http://pdos.csail.mit.edu/~xi/papers/ub-apsys12.pdf and http://pdos.csail.mit.edu/~xi/papers/ub-apsys12-slides.pptx by the same author.