> > Also, why ask for just one byte, since you
> presumably get a whole page anyway?
> > Why not explicitly ask for enough to hold the
> largest fundamental type? If people are going to do
> something stupid like this, they
> > might well be dereferencing _any_ sort of pointer,
> not just char *. Obviously
> > that could be a pointer to a struct or whatever
> too, but that's an open-ended
> > situation, wherein trying to anticipate the scope
> of the foolishness leads to
> > madness. Granted though that passing a NULL to
> something expecting a
> > string is perhaps the most common, and [EMAIL PROTECTED] at least
> allows one to work
> > around that.
>
> I could but then it would mask even more problems
> than [EMAIL PROTECTED] does today
> and that might not be a good thing. At the end of
> the day attempting to
> dereference NULL is a bug in the source and it really
> should dump core
> so it can be fixed.
That's true, and that's why it's not the default behavior, but since
[EMAIL PROTECTED] exists anyway (and I note there's a 64-bit version too, even
though that surely long
postdates the AT&T systems which mistakenly tolerated dereferencing NULL by
default),
the code might as well document the intent. Other than that, AFAICT it makes
zero
difference, since pretty much by definition, mmap() deals in whole pages.
So I'm suggesting a sizeof (_something_) for the 2nd arg of mmap() rather than
1, where
_something_ is either char or long double _Complex (smallest and largest
fundamental types, leaving aside how fundamental one regards _Complex as being)
that is,
(void) mmap(0, sizeof (char) , PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1,
0);
or
(void) mmap(0, sizeof (long double _Complex), PROT_READ,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0);
Looking closer, perhaps the original intent was given by the comment
"...for stupid programs that think a null pointer is as good as a null string",
in which case sizeof(char) would serve to illustrate that the intent was
clearly no
broader than stated (notwithstanding that you got a whole page of read-only
zero bytes,
regardless).
If nothing else, it would be less subject to interpretation, precluding future
instances of
the question.
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
