>"Chris Torek" <no****@torek.n et> wrote in message
news:co******* **@news2.newsgu y.com... There are a number of flawed ideas behind the question to start
with.
In article <41************ ***********@dre ader20.news.xs4 all.nl>
dandelion <da*******@mead ow.net> wrote:Ok. I'm always eager for flawed ideas on my part to be corrected. However,
after a couple of readings it's still not very clear to me what the flaws
were. Or the ideas, for that matter. ...
I remember writing this, and trying to pick out what the assumptions
behind the question might have been, but not precisely what I thought
they could be and thus what was wrong with them. :-)
Seriously, one thing that stood out was the idea that all pointers
were "byte pointers", as it were. The old PR1ME machines had 32-bit
"word pointers" and 48-bit "byte pointers", and even in the mid-1980s,
a new machine that came on the market -- the Data General Eclipse --
had separate *formats* for pointers, with word pointers pointing to
16-or-more-bit data, and byte pointers pointing to 8-bit data. A
word pointer's value was always half as much as the corresponding
byte pointer's value.
Oh, apropos 'flawed idea'... I wanted to amke sure wether the null-pointer
conversion (from 0 to whatever) took place at compile-time. Your post more
than confirmed that.
Yes. I always like to imagine what C might have been like if Dennis
had added a "nil" kewyord. Instead of the klunky Standard C three-word
phrase, "null pointer constant", we would just say "nil". A null
pointer would be obtained by using the keyword "nil" wherever a
pointer is required:
char *p = nil; /* sets p to the "null pointer of type char *" */
or:
(int *)nil /* produces the "null pointer of type int *" */
but if you wrote:
printf("nil prints out as %p\n", nil);
you would get a compile-time diagnostic (error message), because the
prototype for printf() is:
int printf(const char *, ...);
and placing the "nil" keyword in an untyped context would be an
error -- the compiler doesn't know *which* "nil" to use ("byte
pointer null", "word pointer null", etc.) on machines where there
are multiple kinds of "null pointer". You would fix this with:
printf("nil prints out as %p\n", (void *)nil);
The cast provides the context, telling the compiler "use the kind
of null pointer needed for the type `void *'".
Dennis did not do this, though. Instead of a keyword that means
"null pointer of type supplied by context, or error if context is
missing" we have "integral constant expression with value zero".
The problem *only* occurs when the required context is missing.
With a keyword -- whether it were spelled "nil" or "__builtin_null "
or even "_KUMQUAT" -- the compiler would know: aha, context missing,
must complain! With "integral constant zero", on the other hand,
what remains when the context is removed is a valid "int": 0.
Someday (in my copious spare time perhaps :-) ) I should add a
trick to gcc, so that __builtin_nil (or however it is to be spelled)
is an integral constant expression with value 0, except that it
produces a diagnostic message whenever it is used in something
other than a pointer context. Then we can:
#define NULL __builtin_water _buffalo /* or however it is spelled */
and get what we would have now if Dennis had just added the keyword
a long time ago.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
