Path: utzoo!attcan!uunet!unhd!pas
From: pas@uunet!unhd (Paul A. Sand)
Newsgroups: comp.lang.c
Subject: Re: What C compilers have non-zero null pointers?
Message-ID: <1990Jul10.141208.24902@uunet!unhd>
Date: 10 Jul 90 14:12:08 GMT
References: <422@minya.UUCP>
Reply-To: pas@unhd.UUCP (Paul A. Sand)
Organization: University of New Hampshire
Lines: 40

In article <422@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>Anyhow, what's the story here?  Are there really C compilers that
>use something other than all-zero bits for a null pointer?  If so,
>can you name the compilers, and describe their representations and
>how they handle code like the above?

"Certain Prime computers use a value different from all-bits-0 to
encode the null pointer. Also, some large Honeywell-Bull machines use
the bit pattern 06000 to encode the null pointer. On such machines, the
assignment of 0 to a pointer yields the special bit pattern that
designates the null pointer. Similarly, (char *)0 yields the special
bit pattern that designates a null pointer."

-- "Portable C" by H. Rabinowitz and Chaim Schaap, Prentice-Hall, 1990,
page 147.  A good book. Rex Jaeschke's "Portability and the C Language"
(Hayden, 1988) makes the same point but doesn't name names.

>This seems like it could be the source of a lot of fun portability
>problems.  Any insights here?

I bet you're right, although it's rather easy to be careful in these
cases; there are a lot of more common and subtler portability
problems.

These books point out, for example, that calloc() initializes its
allocated memory to all-bits-0.  Interestingly [at least for those
interested by such things] Rabinowitz & Schaap claim that "most C
environments" initialize non-explicitly-initialized static and extern
variables to all-bits-0. On the other hand, Jaeschke claims that such
variables are assigned the value of 0 "cast to their type." Unless
you're working in guaranteed ANSI-land only, I wouldn't rely on
Jaeschke being right.

It's also a good idea, I'm told, to cast the null pointer explictly
when using it as a function argument, for this and other reasons.

-- 
-- Paul A. Sand
-- University of New Hampshire
-- uunet!unhd!pas -or- pas@unh.edu