Path: utzoo!mnetor!uunet!husc6!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!mcnc!rti!sas!bts
From: bts@sas.UUCP (Brian T. Schellenberger)
Newsgroups: comp.lang.c
Subject: Re: Value of a null pointer
Message-ID: <486@sas.UUCP>
Date: 29 Apr 88 04:13:29 GMT
References: <4728@cup.portal.com> <11198@mimsy.UUCP>
Reply-To: bts@sas.UUCP (Brian T. Schellenberger)
Distribution: na
Organization: SAS Institute Inc, Cary NC
Lines: 27

In article <11198@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
|
|[lots of very well-stated true stuff deleted]
|I have heard of one, or perhaps two, efforts at writing compilers for
|machines on which the machine's preferred nil-pointer format was not an
|all zero bit pattern of some appropriate size.  The implementors ran
|into so much code that assumed otherwise that they finally gave in and
|did runtime conversions and tests, rather than using the hardware nil
|types.

We have code running on two such machines (DG & CDC).  On both, you can 
zero out memory with your favorite fill function, and it will still work
just fine.  The first time an address register is loaded, it gets turned 
into the real null-pointer if it used to be binary zero.  Then it is stored.

This means that the only things that screw you up are type-punning (using two
different pointers to the same memory) or incorrect use of unions (which is
really just language-supported type punning).  So you can assign or even stuff
a binary zero into a pointer place, but it may not still look the same if
you examine it in some peculiar way.

This approach allows most sloppy C code to work.
-- 
                                                         --Brian.
(Brian T. Schellenberger)				 ...!mcnc!rti!sas!bts

. . . now at 2400 baud, so maybe I'll stop bothering to flame long includes.