Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU
Newsgroups: comp.windows.x
Subject: Re: X11R4 & strict ANSI
Message-ID: <9009050537.AA02162@Larry.McRCIM.McGill.EDU>
Date: 5 Sep 90 05:37:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 42

>> 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 problem (as described to me by Mr.  Lai) is that NULL is used in
> the X libraries to mean "null character",

Worse than that.

int _XtInheritTranslations = NULL;

(I may have the variable name slightly wrong.)

R4 is shot through with problems like this.  I am currently porting R4
to the NeXT[%], and guess what! NULL is (void *)0.  Xlib, Xt, Xaw, and
perhaps five or ten of the clients have such problems.

[%] Once finished, I will give the result back to MIT and announce it
    here.  Please be patient....

I have been replacing NULL with 0 where this is a problem; in several
of the cases I think it really should be None instead.

There are other problems.  For example,

	extern void bzero();

yields

	"only 1 argument to macro bzero"

(or something similar).  Yes, bzero() is a macro, and it takes two
arguments.  I think there was a third common problem but I can't recall
what it was.  I believe I have the mit/ tree cleaned up, though I've
done it by ruthlessly bashing on it until it works instead of figuring
out proper fixes.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu