Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!columbia!caip!brl-adm!brl-smoke!smoke!HARGED%ti-eg.csnet@CSNET-RELAY.ARPA
From: HARGED%ti-eg.csnet@CSNET-RELAY.ARPA
Newsgroups: net.lang.c
Subject: (foo == 0)
Message-ID: <2272@brl-smoke.ARPA>
Date: Tue, 15-Jul-86 19:21:54 EDT
Article-I.D.: brl-smok.2272
Posted: Tue Jul 15 19:21:54 1986
Date-Received: Wed, 16-Jul-86 03:49:29 EDT
Sender: news@brl-smoke.ARPA
Lines: 31


>>      It never fails to amaze me just how many people do this:
>>              if (foo == NULL) { ... }
>>      or:
>>              if (foo == 0) { ... }
>       [instead of...]
>>              if (!foo) { ... }
>
>       ... I changed because the (!foo)
>       notation is less readable than the (foo == 0) notation.
>
>       Also, if foo is a pointer type, the test (!foo) is wrong. NULL doesn't
>       have to be zero.
>

Like you, I believe the explicit comaprisons are easier to comprehend
when browsing through code than the ubiquitous (!foo) form. In the
explicit comparison cases, generally no performance overhead is incurred
because these are optimizations that are easy to implement. I'm not sure
I'd want to work with a compiler that couldn't perform the necessary
optimizations - if it couldn't, these would cause the least of the
performance penalties you'd pay !

However, the (!foo) form is semantically valid for pointer variables. It
may force an unseen conversion in order to work correctly, but it will
work even when NULL is not represented by 0.

Richard Hargrove
CSNET: harged@ti-eg
ARPA:  harged%ti-eg.arpa@csnet-relay.arpa
-----------------------------------------