Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!astroatc!prairie!dan
From: dan@prairie.UUCP (Daniel M. Frank)
Newsgroups: news.software.b,comp.lang.c
Subject: Re: News for Xenix on PC AT ?
Message-ID: <443@prairie.UUCP>
Date: Fri, 24-Apr-87 23:05:55 EDT
Article-I.D.: prairie.443
Posted: Fri Apr 24 23:05:55 1987
Date-Received: Sun, 26-Apr-87 23:33:38 EDT
References: <18346@ucbvax.BERKELEY.EDU> <145@sds.UUCP> <17005@sun.uucp> <146@sds.UUCP> <5787@brl-smoke.ARPA>
Reply-To: dan@prairie.UUCP (Daniel M. Frank)
Organization: Prairie Computing, Madison, Wisconsin
Lines: 24
Xref: mnetor news.software.b:550 comp.lang.c:1904

In article <5787@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>He, I, and others have explained more than once before in the C newsgroup
>that the only fully correct definition of the macro NULL, as C now stands,
>is as 0.  (Under the proposed ANSI standard you could probably get away
>with defining it as (void *)0.)

   No.  On the 8086 family, in large model, if NULL is defined as 0, then
such things as 

	execl(..., NULL) ;

will fail, because a pointer (32-bit) parameter is expected, and an int
(16-bit) parameter is passed, with some garbage in the stack making up the
difference.  Lint will not catch this, either, because execl is /*VARARGS*/.

   It's pretty safe to define NULL as 0L when in large model, but the best
solution of all is (void *)0, or type-specific NULLs (i.e. NULLCHAR).
The (void *)0 solution may cause problems with lint, though.

-- 
      Dan Frank (w9nk)
	ARPA: dan@db.wisc.edu			ATT: (608) 255-0002 (home)
	UUCP: ... uwvax!prairie!dan		     (608) 262-4196 (office)
	SNAILMAIL: 1802 Keyes Ave. Madison, WI 53711-2006