Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!BARNES@TL-20A.ARPA
From: BARNES@TL-20A.ARPA
Newsgroups: net.unix-wizards
Subject: Re: Xenix286 Wonders, Bugs, and Patches...
Message-ID: <10550@brl-tgr.ARPA>
Date: Thu, 9-May-85 15:17:25 EDT
Article-I.D.: brl-tgr.10550
Posted: Thu May  9 15:17:25 1985
Date-Received: Sat, 11-May-85 08:23:07 EDT
Sender: news@brl-tgr.ARPA
Lines: 30

In article <2158@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>
>> 	exec() doesn't always work with the large model due to NULL being
>>	placed at the end of the arg list instead of (char *)NULL.  This is a
>> 	programmer problem more than a bug.
>> 
>> 	system() doesn't work in the large model if the si register is
>>	non-zero.  This is due to the exec() error above.  They used NULL
>>	instead of (char *) NULL...
>
>The former is not at all a bug.  *Good* programmers know to cast null
>pointers properly.  Other programmers write code that breaks on all the
>machines out there with 16-bit "int"s and > 16-bit pointers...

NULL is usually declared in stdio.h as:
	#define NULL 0
Kernighan & Ritchie on page 98 state explicitly that, "In general, integers
cannot meaningfully be assigned to pointers; zero is a special case."  On the
previous page they state, "C guarantees that no pointer that validly points at
data will contain zero, ..."

Thus, the code is not buggy in the least; with or without casting.  If code
such as:
	struct mumble *p;
	...
	p = 0;
does not assign a 32-bit wide zero on a machine with 16-bit int's and 32-bit
pointers then you don't have a buggy program.  You have a buggy compiler that
needs fixing.
-------