Topic: Testing for null pointers (was that NULL vs. 0 thread)


Author: grumpy@cbnewse.cb.att.com (Paul J Lucas)
Date: Sun, 10 Oct 1993 19:46:24 GMT
Raw View
 Ok, with all this talk about 0 vs. NULL, and the fact that the
 nil pointer is not necessarily represented by a bit pattern of
 all zeros, are the following statements equivalent?

  int *p = 0;

  if ( p != 0 ) // ...
  if ( p ) // ...

 and

  if ( p == 0 ) // ...
  if ( !p ) // ...

 Are the two latter forms equivalent to their two respective former
 forms?  I can't find anything in the ARM that says so.  All the
 examples do explicit comparisons against 0.

 So, assuming that on machine/implementation X/Y nil pointers are
 *not* represented by a bit pattern of all zeros, does C++
 convert the value of expressions like the latter ones given to
 nonzero/non representing non-nil/nil so that the tests will
 work as intended?

 I would assume that C and C++ agree here, but I can't find
 anything that addresses this directly in the C ref. manual
 either.
--
 - Paul J. Lucas
   AT&T Bell Laboratories
   Naperville, IL




Author: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Date: Mon, 11 Oct 1993 09:01:34 GMT
Raw View
grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:

> Ok, with all this talk about 0 vs. NULL, and the fact that the
> nil pointer is not necessarily represented by a bit pattern of
> all zeros, are the following statements equivalent?

Amazing - C/C++'s use of 0 to represent a null pointer has confused even
Paul Lucas! :-)

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU




Author: pkt@lpi.liant.com (Scott Turner)
Date: Mon, 11 Oct 1993 14:09:28 GMT
Raw View
In article <CEp5LE.8v4@cbnewse.cb.att.com>, grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:
>   if ( p != 0 ) // ...
>   if ( p ) // ...
>
>  and
>
>   if ( p == 0 ) // ...
>   if ( !p ) // ...
>
>  Are the two latter forms equivalent to their two respective former
>  forms?  I can't find anything in the ARM that says so.

Regarding
 if ( p ) ...
the C++ standards committee has amended the ARM's wording
from
 if [the expression] is nonzero
to
 if [the expression] is nonzero (for arithmetic types)
 or non-null (for pointer or pointer-to-member types)

The committee's working paper has a similar fix for unary '!'.  I hope
that resolves your concern.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com




Author: rubenst%occs.nlm.nih.gov (Michael M. Rubenstein)
Date: Tue, 12 Oct 93 02:58:52 GMT
Raw View
Paul J Lucas (grumpy@cbnewse.cb.att.com) wrote:
>  Ok, with all this talk about 0 vs. NULL, and the fact that the
>  nil pointer is not necessarily represented by a bit pattern of
>  all zeros, are the following statements equivalent?

>   int *p = 0;

>   if ( p != 0 ) // ...
>   if ( p ) // ...

>  and

>   if ( p == 0 ) // ...
>   if ( !p ) // ...
>
>  Are the two latter forms equivalent to their two respective former
>  forms?  I can't find anything in the ARM that says so.  All the
>  examples do explicit comparisons against 0.

>  So, assuming that on machine/implementation X/Y nil pointers are
>  *not* represented by a bit pattern of all zeros, does C++
>  convert the value of expressions like the latter ones given to
>  nonzero/non representing non-nil/nil so that the tests will
>  work as intended?

>  I would assume that C and C++ agree here, but I can't find
>  anything that addresses this directly in the C ref. manual
>  either.

My reading of the ANSI (ISO) C standard is that it does require this:

 The result of the logical negation operator ! is 0 if the value
 of its operand compares unequal to 0, 1 if the value of its
 operand compares equal to 0.  The expression !E is equivalent to
 (0==E)

  6.3.3.3

 In both forms [of the if statement (with and without "else")],  the
 first statement is executed if the expression compares unequal to 0.

  6.6.4.1

6.3.3.3 is clear.  6.6.4.1 is clear if one takes "0" to mean a constant 0, not
simply a 0 value; I believe this is the only reasonable interpretation.

--
Mike Rubenstein