From:	Dag Nummedal <nummedal AT pvv DOT unit DOT no>
Date:	Fri, 4 Nov 94 16:02:00 +0100
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: NULL pointers...
References:	<9411031749 DOT AA29953 AT nova DOT pvv DOT unit DOT no>
	<9411040323 DOT AA29409 AT delorie>

DJ Delorie writes:
 > >  > Hmm...  I would guess that having NULL != (void *) 0, even if it's not
 > >  > supposed to be guaranteed to be that in the first place, would break more code
 > >  > than we'd all like to imagine.
 > > 
 > > Actually the above cast, and (char *)0, (int *)0 etc. would still work.
 > 
 > At Cabletron, we discovered that the ONLY definition for NULL that
 > worked reliably was "0".  Note that "(void *)0" did NOT work reliably,
 > so I doubt that "(void *)(-1)" would work any better.

The point pjones AT acs DOT bu DOT edu made was not to change the definition of
	#define NULL 0
to 
	#define NULL some_large_number

The point was to get GCC to change its interneal represantation of the token
0, used in a pointer context. That is:
	int *p = 0
would in assembly make p point to a high memory location, not to memory
location zero.

This way only badly broken C-code, that assumes that:
	int i = 0
can be cast to a null pointer, would fail.

The problem with this is that probably most of libc and go32 (at least the
assembly parts) would assume that the null pointer points to memory location
zero.

If implemented, this could catch a lot of bad code, but it would also make
porting programs to DJGPP harder.

-Dag Nummedal

- Raw text -