Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!itsgw!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.lang.c
Subject: Re: uustatus - realtime uustat for HDB uucp (w/findpath)
Keywords: NULL zero 0 C Microsoft
Message-ID: <13048@steinmetz.ge.com>
Date: 30 Jan 89 13:21:24 GMT
References: <1167@unisec.usi.com> <5312@turnkey.TCC.COM> <1989Jan30.013936.11995@gpu.utcs.toronto.edu>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 51

In article <1989Jan30.013936.11995@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes:
| 
| What I'm about to say is really just a flame, but at the same time, I
| don't want to start a war either.  This is posted, instead of being
| mailed, out of general frustration at a very obvious mis-understanding
| that has perpetuated itself for far too long.

  What I am going to say is a flame, too. The ANSI standard for C says
that NULL will return a pointer constant. Not an integer constant,
*pointer*. Section 4.1.5, line 4, page 96. Please stop posting your
opinion as fact. What you mean is that K&R used NULL and you wish it
hadn't changed. Anyone who writes portable code never assumes integet
*or* pointer, but casts it as needed and uses zero when they mean zero.

| The reason your compiler gives you a warning message, is because NULL
| has been erroneously defined as something other than just plain zero.  I
	See above. "Erroneously defined" to meet the ANSI standard.
| most definitely will not go into the reasons why, but it should suffice
| to say that "#define NULL 0" is the only correct definition.  [Anyone
	It should suffice to say that you are wrong.
| who would like some evidence, please send me some mail.]
| 
| The only unfortunate side-effect of this is the potential breaking of
| any programmes that were written with the assumption that NULL is
| defined as something other than zero.
	Correct! Older programs which used NULL as if it were zero will
fail under ANSI compilers. So will Pascal programs. They are not 100%
compatible, although it is possible to write in that set of features
shared by K&R and ANSI.
| 
| As another point of warning, be careful of the Microsoft C iAPX86
| compiler that you are most likely using with your version of Xenix.
| Some versions of this compiler do not properly perform pointer
| arithmetic with zero, unless it is cast to a pointer type.
	The effect of pointer-int is well defined, which is what I
assume you mean. NULL is treated as an address, which will cause strange
side effects if you think it's an int (and also if you think that a zero
should be treated as an address).

	Your assumption that NULL was zero in K&R C (1st ed) is correct,
and 2nd ed. could be read to say that, although their explanation (pg
102) states assignment and comparison with pointers. In the assumption
that NULL is incorrect if defined as a pointer, you are obviously in
conflict with the ANSI standard.

	In my opinion any code which assumed the type of NULL as either
int or pointer will break on some machine.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me