Re: [PATCH] Fix some sparse warnings
- From
Philip Oakley <philipoakley@iee.org>
- Date
- Jul 16, 2013, 22:18 UTC
- Message-ID
- <51E5C6D1.7000505@iee.org>
- In-Reply-To
- <51E5B8BD.8090202@googlemail.com>
On 16/07/13 22:18, Stefan Beller wrote:
Show 80 quoted lines
> On 07/16/2013 10:53 PM, Philip Oakley wrote:
>> From: "Jeff King" <peff@peff.net>
>> 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.