Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!utcsri!greg
From: greg@utcsri.UUCP
Newsgroups: news.software.b,comp.lang.c
Subject: Re: News for Xenix on PC AT ?
Message-ID: <4681@utcsri.UUCP>
Date: Mon, 27-Apr-87 13:33:13 EDT
Article-I.D.: utcsri.4681
Posted: Mon Apr 27 13:33:13 1987
Date-Received: Tue, 28-Apr-87 00:56:42 EDT
References: <18346@ucbvax.BERKELEY.EDU> <145@sds.UUCP> <17005@sun.uucp> <146@sds.UUCP> <17245@sun.uucp> <889@viper.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 32
Xref: utgpu news.software.b:528 comp.lang.c:1844
Summary: 

In article <889@viper.UUCP> john@viper.UUCP (John Stanley) writes:
> >  The C language lacks a token like Pascal's "nil", so a
> >constant expression with the value 0 must do double duty as a
> >representation of a null pointer.  
>
>  Wrong...  Ever hear of something called "NULL"?
>
>K&R, Page 97:
>  "We write NULL instead of zero, however, to indicate clearly that
>this is a special value for a pointer."...

But NULL is #defined as 0, so this is nothing but a commenting device in
K & R C.
The two classic examples where it fails to work are:

	func_expecting_char_ptr(NULL);

func(0) causes an *int* to be pushed.

	char_ptr = a<b? NULL: NULL;

The RHS of the assignment is not a constant with type int and value 0,
so the above is not legal ( as opposed to "a<b? char_ptr:0 ", in which
the 0 is converted to a null char * by virtue of it being across the :
from one ).

Both of these can be fixed by the up-and-coming semantics of void* (NULL being
defined as ((void*)0) ), and function prototypes won't hurt.
-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...