Date: Mon, 12 Jan 1998 18:19:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: tlambert@primenet.com, jamie@itribe.net, jdevale@ece.cmu.edu, hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards Message-ID: <199801121819.LAA24153@usr04.primenet.com> In-Reply-To: <199801100346.TAA04537@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Jan 9, 98 07:46:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> * 1) Map a zero filled page to page zero. This causes the NULL > * to be treated, incorrectly, as a NULL valued string instead > * of a NULL. A process which is still running can be examined > * via /proc for the address space mappings to see if it has > * triggered the page 0 mapping. > > What the bleep is a "NULL valued string"? Are you aware that the > so-called NULL pointer (or rather "0 in a pointer context") is not > necessarily equal to a bit string of all zero's? (What was that > example of this not being true, hmm, was it a PDP-11?) If you map a zero filled page to page zero, then a dereference of page zero (ie: a NULL pointer) returns a string of zeros. The PDP/11 had a string that was non-NULL mapped at page zero because the process mapping started at page 0, and so the PDP/11 "magic" was referenced instead of a bit string of all zeros (0177555, if my memory is not failing -- that's an octal short.). Also, you're right that the standard allows for a non-zero value for NULL. I don't know of anyone who uses this; it's pretty much in there to cause problems, like a lot of other "features", ie: the assumption that certain optimizations are allowable unless they are explicitly disallowed, etc.. > Oh, you mean an empty string? Oh, ok. That has nothing to do with > NULL though. (And there is no such thing as "NULL byte"...try "null > character' instead.) Heh. I expected SEF to stomp in my cheerios here first. 8-). If you: #include <stdio.h> main() { char c = NULL; printf( "The value of a NULL character is %d\n", c); exit( 0); } The program, when compiled, does not bitch about the "loss of precision" in the assignment in the declaration of 'c'. 8-). The program, when run, displays: The value of a NULL character is 0 I'd say the compiler says that 'c' is a "NULL character", until it bitches, properly, about the assignment. The useful thing about thinking about it this way is that wchar_t types keep working, whereas if I defined a "null character" on a non-two's complement architecture, it would be damaged to a non-zero valued wchar_t on sign extension. Heh. So pretty much until you fix the compiler, I'm going to keep my terminology as fuzzy as the compiler's enforcement. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801121819.LAA24153>