From owner-freebsd-hackers Mon Jan 12 10:20:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA07156 for hackers-outgoing; Mon, 12 Jan 1998 10:20:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA07055 for ; Mon, 12 Jan 1998 10:19:59 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA02888; Mon, 12 Jan 1998 11:19:58 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd002840; Mon Jan 12 11:19:52 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id LAA24153; Mon, 12 Jan 1998 11:19:47 -0700 (MST) From: Terry Lambert Message-Id: <199801121819.LAA24153@usr04.primenet.com> Subject: Re: FreeBSD Netcards To: asami@cs.berkeley.edu (Satoshi Asami) Date: Mon, 12 Jan 1998 18:19:47 +0000 (GMT) Cc: tlambert@primenet.com, jamie@itribe.net, jdevale@ece.cmu.edu, hackers@FreeBSD.ORG In-Reply-To: <199801100346.TAA04537@silvia.HIP.Berkeley.EDU> from "Satoshi Asami" at Jan 9, 98 07:46:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > * 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 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.