Re: [PATCH 1/2] staging/sep: Fix smatch false positive aboutpotential NULL dereference in sep_main.c
From: Dan Carpenter
Date: Tue Feb 19 2013 - 07:25:43 EST
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.
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/