On Feb 17, 2011, at 9:49 AM, Gerald Combs wrote:
> However this produces an error:
>
> --------
> #include <malloc.h>
>
> void f( )
> {
> char *p;
> int testval = 1;
>
> if ((p = ( char * ) malloc( 10 )) && testval) {
> *p = '\0';
> free( p );
> }
> }
> --------
>
> test.c(9) : warning C6011: Dereferencing NULL pointer 'p': Lines: 5, 6, 8, 9
I suspect that
if (testval && (p = ( char * ) malloc( 10 ))) {
would also produce a warning.
My guess is that
1) whatever intermediate representation the code analyzer is handed represents "p" and "p != 0" differently - which makes sense, given that
a = p;
and
a = (p != 0);
aren't the same thing
but
2) the code analyzer is smart enough to know that, when used as the expression in an if statement, "p" tests whether the pointer is null, so in
if (p) {
use p
}
p is known to be non-null, but it isn't smart enough to know that if "p" is used in, for example, a short-circuit Boolean expression, it also tests whether it's null, so in
if (p && q) {
use p
}
or
if (q && p) {
use p
}
p is known to be non-null.
So, until this bug is fixed, we either need to remember which of the "Dereferencing NULL pointer" warnings are bogus, put in a #pragma to disable ones we know to be bogus if that's possible, keep checking them every time, or use "p != NULL" or "p == NULL" rather than "p" or "!p" in short-circuit Boolean expressions.
