Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: references to dereferenced null pointers
Message-ID: <16189@haddock.ima.isc.com>
Date: 16 Mar 90 00:34:58 GMT
References: <51083@microsoft.UUCP> <25EB8EE8.8462@paris.ics.uci.edu> <1990Mar12.175613.12082@utzoo.uucp> <1623@argus.UUCP> <1990Mar14.164539.23685@utzoo.uucp> <16179@haddock.ima.isc.com> <945@ns-mx.uiowa.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 22

In article <945@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes:
>The bottom line in actual practice is that if NULL isn't a binary object
>of all zero bits, you can get into trouble porting programs.  Using 0 and
>NULL interchangebly is an unfortunate but common practice -- see code
>examples in Stroustroup's C++ book -- many assignments of 0 to pointers.

As I just finished saying, those are quite legal and do not cause a problem on
"strange-NULL" implementations.  (I presume we're talking about *constant* 0.)

>would be aided by a compiler that would flag ALL assignments of
>non-pointer constants to pointer variables.

I would hope that *any* modern compiler would flag a pointer-vs-int collision!

>[An explicit pointer-to-integer cast can still cause problems]
>[Also, some programs use small integer constants as sentinels]

I'll admit that these two are problem situtations, but I doubt they're all
that common.  And you don't have to have a "strange-NULL" architecture for
them to break.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint