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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
