Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: X11R4 & RS6000 (again)
Message-ID: <4023@auspex.auspex.com>
Date: 5 Sep 90 01:44:29 GMT
References: <9008301739.AA14217@hydrogen.chem.utah.edu> <890@dimebox.cs.utexas.edu>
Organization: Auspex Systems, Santa Clara
Lines: 38

>The only (but don't hold me to this) other change I had to make was to
>redefine NULL as 0; NULL is (void *) in ANSI C, and caused lots of
>incompatible-type problems for `xlc'. 

Actually, NULL can either be 0 or "(void *)0" in ANSI C (the actual text
in the ANSI C standard speaks of "integral constant expressions with the
value 0", but anybody who #defines NULL as (1-1) should be shot).  The
problem (as described to me by Mr.  Lai) is that NULL is used in the X
libraries to mean "null character", e.g. in "XrmParseCommand" in
"ParseCmd.c":

	...

    char		*optP, *argP, optchar, argchar;

	...

	    for (argP = *argv, optP = options[i].option;
		 (optchar = *optP++) != NULL &&
		 (argchar = *argP++) != NULL &&
		 argchar == optchar;);

which, if NULL is #defined as "(void *)0" or something such as that,
ends up comparing a "char" variable with "(void *)0".  That ain't a
valid comparison in ANSI C, and IBM's compiler is perfectly justified in
rejecting it.

If somebody insists on spelling '\0' as something pronounced "null", I
suggest NUL, that being the name of the character in ASCII. 
Alternatively, you can just call it '\0' and not worry about it.

In *any* case, please resist the temptation to compare anything other
than pointers with NULL, or to assign NULL to anything other than a
pointer, or to return it from a function returning anything other than a
pointer, etc., and consider fixing up existing code that does any of the
aforementioned.  Those with strict C compilers and C implementations
that define NULL as "(void *)0" (e.g., the RS6000 C implementation, from
what Mr. Lai says) will thank you.