can "if (ptr)" cause problems?

[vl106]

A static code analysis tool gave me a warning on

if (ptr && ptr->data) { ... }

I assumed the tool doesn't get the "short circuit behaviour" in
the if statement.

But a collegue said it may be the missing check ot ptr against
NULL.

What happens on an architecture where NULL isn't address
with all bits set to zero (e.g. 0xffff)? In this case my if-statement
will fail.

Does that mean the only portable way is "if (ptr != NULL)?.
if (ptr) and if (!ptr) would then be non-portable?

Thanks for your help.

 

[Frederick Gotham]

vl106:

A static code analysis tool gave me a warning on

if (ptr && ptr->data) { ... }

What kind of warning?

All I can tell you is that the code is equivalent to:

if (ptr) if (ptr->data) ... ;

 

[dcorbit]

A static code analysis tool gave me a warning on

if (ptr && ptr->data) { ... }

I assumed the tool doesn't get the "short circuit behaviour" in
the if statement.

But a collegue said it may be the missing check ot ptr against
NULL.

What happens on an architecture where NULL isn't address
with all bits set to zero (e.g. 0xffff)? In this case my if-statement
will fail.

Does that mean the only portable way is "if (ptr != NULL)?.
if (ptr) and if (!ptr) would then be non-portable?

Thanks for your help.

It could be a problem, but not for the reasons stated.

If ptr is uninitialized, the code invokes undefined behavior.

What (exactly) was the warning message?

 

[Ben Pfaff]

A static code analysis tool gave me a warning on

if (ptr && ptr->data) { ... }

I assumed the tool doesn't get the "short circuit behaviour" in
the if statement.

But a collegue said it may be the missing check ot ptr against
NULL.

This is a FAQ.

5.3: Is the abbreviated pointer comparison "if(p)" to test for non-
null pointers valid? What if the internal representation for
null pointers is nonzero?

A: When C requires the Boolean value of an expression, a false
value is inferred when the expression compares equal to zero,
and a true value otherwise. That is, whenever one writes

if(expr)

where "expr" is any expression at all, the compiler essentially
acts as if it had been written as

if((expr) != 0)

Substituting the trivial pointer expression "p" for "expr", we
have

if(p) is equivalent to if(p != 0)

and this is a comparison context, so the compiler can tell that
the (implicit) 0 is actually a null pointer constant, and use
the correct null pointer value. There is no trickery involved
here; compilers do work this way, and generate identical code
for both constructs. The internal representation of a null
pointer does *not* matter.

The boolean negation operator, !, can be described as follows:

!expr is essentially equivalent to (expr)?0:1
or to ((expr) == 0)

which leads to the conclusion that

if(!p) is equivalent to if(p == 0)

"Abbreviations" such as if(p), though perfectly legal, are
considered by some to be bad style (and by others to be good
style; see question 17.10).

See also question 9.2.

References: K&R2 Sec. A7.4.7 p. 204; ISO Sec. 6.3.3.3,
Sec. 6.3.9, Sec. 6.3.13, Sec. 6.3.14, Sec. 6.3.15, Sec. 6.6.4.1,
Sec. 6.6.5; H&S Sec. 5.3.2 p. 122.

 

[Christopher Benson-Manica]

If ptr is uninitialized, the code invokes undefined behavior.

UB also results if the value of ptr has been passed to free().

 

[Gordon Burditt]

A static code analysis tool gave me a warning on

if (ptr && ptr->data) { ... }

I assumed the tool doesn't get the "short circuit behaviour" in
the if statement.

Tools and ANSI-compliant C compilers are different things.
It might be complaining about ptr being *uninitialized*, rather
than a null pointer.

But a collegue said it may be the missing check ot ptr against
NULL.

This statement is equivalent to
if (ptr != NULL && ptr->data != NULL) { ... }

*EVEN IF* the internal bit representation of a null pointer
is not 0xdeadbeef (or on 64-bit systems, 0xdeadbeefdeadbeef).

What happens on an architecture where NULL isn't address
with all bits set to zero (e.g. 0xffff)? In this case my if-statement
will fail.

No, it won't fail. Your statement works regardless of the bit
representation of a null pointer. ANSI C makes no guarantee that
a null pointer MUST be represented by 0xdeadbeef, even on 32-bit
systems, and some of them don't.

Does that mean the only portable way is "if (ptr != NULL)?.
if (ptr) and if (!ptr) would then be non-portable?

No.

 

[pete]

UB also results if the value of ptr has been passed to free().

.... not if the value of ptr is equal to NULL.