negative addresses

T. William Wells bill at proxftl.UUCP
Mon May 23 11:34:21 AEST 1988


In article <10001 at tekecs.TEK.COM>, andrew at frip.gwd.tek.com (Andrew Klossner) writes:
> Doug Gwyn (gwyn at brl-smoke.ARPA) writes:
>
> >> Unfortunately, it is a real problem, because there are zillions of
> >> programs that implicitly assume that [null] pointers are all-zeros.
>
> > I don't think this is true.  How about an example?
>
> Sure Doug, from the system V kernel that you defend so ardently :-),
> file io/tt1.c (vanilla release 3.1):
>
> In routine ttout:
>
>               if (tbuf->c_ptr)
>
> appears twice.  (And in the same routine,
>
>               if (tbuf->c_ptr == NULL)

ANSI says that the two are equivalent.  Actually, ANSI says
(about `if'): "...  the first substatement is executed if the
expression compares unequal to 0.  ...".  This means that you can
think of the statement `if (x)' as `if (x != 0)'.

Note that ANSI only insists that `pointer == 0' be true if and
only if pointer is a null pointer; it makes no requirements that
the pointer actually contain any zeros.

For example, on an 8086, you could define a null pointer as one
with a zero (or any other value) offset.  An implicit or explicit
compare of the pointer to zero would then check only the offset.

An interesting point: ANSI does not define (at least not anywhere
I can find it) the result of `x == y' when x and y are both null
pointers.  Actually, a literal reading of the standard implies
that this would compare false!  Here is my reasoning.  The
standard says that "If two pointers ...  compare equal, they
point to the same object." Since a null pointer does not point to
ANY object, comparing anything to a null pointer should return
false.

I hope that this is an oversight.



More information about the Comp.lang.c mailing list