Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site rabbit.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!harpo!eagle!allegra!alice!rabbit!mjs
From: mjs@rabbit.UUCP
Newsgroups: net.unix-wizards
Subject: Re: NULL vs 0
Message-ID: <2406@rabbit.UUCP>
Date: Thu, 19-Jan-84 08:46:08 EST
Article-I.D.: rabbit.2406
Posted: Thu Jan 19 08:46:08 1984
Date-Received: Fri, 20-Jan-84 06:06:18 EST
References: <345@hocda.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 28

The point is that there are an increasing number of machines whose
compilers choose 16 bits to represent an int, and 32 for a pointer.  On
such a machine, the following code is simply wrong:

	#define	NULL ((char *) 0)
	int f(p,x,y)
	char * p; int x, y;
	{
		/* stuff */
		return (x);
	}

	int g()
	{
	#ifdef	INCORRECT
		(void) f(0, 17, 42);	/* 3 16-bit quantities */
	#else	!INCORRECT
		(void) f(NULL, 17, 42);	/* 32 bits of 0 & 2 16-bit ints */
	#endif	INCORRECT
	}

All that's been asked of anyone is to enhance portability to machines
where it is advantageous (due to things like bus bandwidth, cpu power,
etc.) to use 16 bits to represent type int, and 32 for pointer types.
-- 
	Marty Shannon
UUCP:	{alice,rabbit,research}!mjs
Phone:	201-582-3199