Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!lll-crg!lll-lcc!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.lang.c Subject: Re: ANSI C Message-ID: <6237@sun.uucp> Date: Sat, 16-Aug-86 05:09:13 EDT Article-I.D.: sun.6237 Posted: Sat Aug 16 05:09:13 1986 Date-Received: Sun, 17-Aug-86 10:17:49 EDT References: <86900009@haddock> <86900017@haddock> Organization: Sun Microsystems, Inc. Lines: 75 > It's not too late. In the first place, NULL already exists for this purpose > (though some people insist on using it as a synonym for '\0' too!) If zero- > in-pointer-context henceforth produces a warning message, people will > convert their programs to use NULL instead. Yes, but I don't know whether the disruption that would cause at this late date would be worth the advantages the changes you suggest would bring. 1) I've seen a fair amount of code that does things like *p; ... if (p == 0) (which is perfectly legitimate and type-correct C) and makes calls like execl("/bin/cat", "cat", "file", (char *)0); 2) What happens to code like *p; ... if (p) or if (!p) which is also, at least by my interpretation of the August 11, 1985 ANSI C draft, perfectly legitimate and type-correct C. The discussions of Boolean objects (now that Root Boy is gone, I guess we can acknowledge the existence of Boolean objects in C again) in the draft talk use terms like "equals 0" or "does not equal 0"; I presume some expression X "equals 0" iff X == 0, and "does not equal 0" iff X != 0. Both of those comparisons can be done on pointers. The code in both these examples will have to be changed. The ANSI C committee is at least trying not to break existing code any more than is absolutely necessary. > NULL would presumably be changed from "0" to an implementation-defined > constant like "(void *)0xF0000000". Blech! I suppose the compiler will recognize expressions like that and, if it treats null pointers in any special way, will treat them as such, but it seems ugly. (Yes, a compiler *could* treat them in usefully special ways. For instance, it might try to do dataflow analysis and figure out whether you run the risk of dereferencing a NULL pointer or not. Said dataflow analysis would have to be interprocedural, of course, and cross module boundaries; however, given the depressing amount of crap code out there that is careless about null pointers, it might be worth it.) > Hmm, there's a similar problem without the full-check conversion. If the > constant zero is converted into a null pointer constant, and zero is a valid > address, and something of interest is at that absolute address, how do I > reference it? "x = *(int *)0" will try to dereference NULL instead of 0, > and "i = 0; x = *(int *)i" will undoubtable fail on some optimizing > compilers. Why? If the compiler implements C, it will NOT combine the two statements into one, since the meaning of "x = *(int *)0" is undefined, but the meaning of "x = *(int *)i" is defined to the extent that conversions of "int" to "int *" is defined. The optimizer might decide that the value of "i" is known at that point, and compute the value of "(int *)0" at compile time, and generate code to load the "int" value that would be located at that address into "x". It might then discover that "i" is dead at that point, and throw it away. No C compiler will generate code to dereference a null pointer for that example; any compiler that does is compiling a language other than C. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)