By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,824 Members | 1,255 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,824 IT Pros & Developers. It's quick & easy.

can "if (ptr)" cause problems?

P: n/a
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.
Nov 17 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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) ... ;

--

Frederick Gotham
Nov 17 '06 #2

P: n/a

vl106 wrote:
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?

Nov 17 '06 #3

P: n/a
"vl106" <vl***@hotmail.comwrites:
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.

--
Just another C hacker.
Nov 17 '06 #4

P: n/a
dc*****@connx.com wrote:
vl106 wrote:

if (ptr && ptr->data) { ... }
If ptr is uninitialized, the code invokes undefined behavior.
UB also results if the value of ptr has been passed to free().

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Nov 17 '06 #5

P: n/a
>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.
Nov 17 '06 #6

P: n/a
Christopher Benson-Manica wrote:
>
dc*****@connx.com wrote:
vl106 wrote:
>
if (ptr && ptr->data) { ... }
If ptr is uninitialized, the code invokes undefined behavior.

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

--
pete
Nov 18 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.