From owner-freebsd-hackers Mon Jan 19 11:51:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA10673 for hackers-outgoing; Mon, 19 Jan 1998 11:51:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA10444 for ; Mon, 19 Jan 1998 11:48:58 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id MAA03704; Mon, 19 Jan 1998 12:48:47 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd003683; Mon Jan 19 12:48:45 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA05774; Mon, 19 Jan 1998 12:47:18 -0700 (MST) From: Terry Lambert Message-Id: <199801191947.MAA05774@usr08.primenet.com> Subject: Re: FreeBSD Netcards To: dag-erli@ifi.uio.no (Dag-Erling Coidan Sm?rgrav) Date: Mon, 19 Jan 1998 19:47:18 +0000 (GMT) Cc: tlambert@primenet.com, asami@cs.berkeley.edu, jamie@itribe.net, jdevale@ece.cmu.edu, hackers@FreeBSD.ORG In-Reply-To: from "Dag-Erling Coidan Sm?rgrav" at Jan 19, 98 03:39:35 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > Therefore, it is *perfectly correct* for the compiler to produce code > that outputs "The value of a NULL character is 0" from the source code > you give, since what you wrote is, in effect, > > char c = 0; Just because the literal zero can be translated to the NULL pointer does *NOT* mean that the NULL pointer can (or should) be translated to a literal zero. In point of fact, the reason my program prints what it prints is because the behaviour is undefined by the compiler, and this is what *happenS* to happen in this instance. It is my argument that the compiler should issue warnings for undefined behaviours. After all it is *supposedly* a C compiler, and thus *supposedly* has knowledge of the standards hard-coded into it. > > 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.. > > The standard does *not* allow for a non-zero value of NULL. The > standard very clearly states that the literal 0, when assigned to a > pointer variable, evaluates to a NULL pointer. The standard does not, > however, say anything about the internal representation of a NULL > pointer. Wether or not a NULL pointer is all bits zero is > implementation-defined. As is wheter or not the "evaluation" you reference is run time or compile time. If it is compile time, then again, it makes sense to warn about the conversion of a pointer type to a non-pointer type. > > So pretty much until you fix the compiler, I'm going to keep my > > terminology as fuzzy as the compiler's enforcement. > > Again, nothing is wrong with the compiler. It's in perfect accordance > with the ISO C standard. Your use of NULL in "a NULL string" or "the > NULL character", however, is definitely incorrect. Instead, you should > use "an empty string" and "the NUL character" (only one L), > respectively. My DEC ASCII chart that came with my old VT102 says "NULL" with two "L"'s. The three character representation of this is convention, nothing more. Further, I stated "NULL valued string", not "NULL string". While this is subject to interpretation, in context it was pretty obvious that it could mean only one thing and continue to make sense. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.