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>