Re: [PATCH 1/2] staging/sep: Fix smatch false positive aboutpotential NULL dereference in sep_main.c

[Dan Carpenter]

On Tue, Feb 19, 2013 at 01:07:27PM +0100, Peter Huewe wrote:
> Smatch complains about a potential NULL pointer dereference:
> 
> sep_main.c:2312 sep_construct_dma_tables_from_lli() error: potential
> NULL dereference 'info_out_entry_ptr'.
> 
> info_out_entry_ptr is initialized with NULL and if info_in_entry_ptr is
> not NULL it gets derefenced.
> However info_out_entry_ptr is only NULL in the first iteration of the
> while loop and in this case info_in_entry_ptr is also NULL (as indicated
> by the comment /* If info entry is null - this is the first table built */
> -> this is a false positive.
> 
> Nevertheless we add a check for info_out_entry_ptr to silence this
> warning and make it more robust in regard to code changes.
> 

Smatch doesn't handle loops very well.  Of course, all along I've
wanted to fix this, but it's a bit complicated so it could be
another year or two before it actually happens.

Generally, as a philosophy, I always say never to change the code
for false positives.  It should be Smatch which changes.

Also the other thing is that with Smatch I deliberately allow more
false positives than GCC does.  It's a trade off between being
ambitious in looking for bugs and being annoying to users.

When Smatch looks at this code it sees the else side as impossible
to reach.  Perhaps I should add a hack in that if the code is in an
impossible to reach place then don't print a warning...  It would
be better to just fix loop handling...  I'm not sure.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/