Pete French
Tue, 12 Dec 2000 02:33:47 -0800
> It's not an oversight at all. A zero-valued pointer is not an integer, and
> cannot be implicitly cast to an integer. In the situations where NULL can
In which case assigning it to an integer probably is an oversight surely ? i.e.
they meant to write x = 0 rather than x = NULL. I think you'll find a lot
of cheap compilers still have '#define NULL 0' and thus such a thing compiles
without an error unfortunately. Im so glad I dont work with PC's...
> be assigned to an integer it has usually been defined as 0. That can cause
If you ever try making it anything other than zero it will break a lot of
code. People still tend to do things like...
x = malloc(1234)
if(!x) {
puts("malloc failed");
return;
}
which only works if you have NULL as zero (or if you change the semantics of
the way 'if' works when applied to pointers, which I am not sure is allowed
by the standard is it ?)
I never worried about this until I worked with transputers - these beasties
have a signed address space. Thus 0 is right in the middle of RAM and is
a perfectly valid return value from malloc(). Hmmm. No idea how their C
compilers got round that one. I guess the correct definition would be
something like #define NULL ~((unsigned int)(((unsigned int)~0)>>1)) - but
that pretty unpleasent really.
-bat. [and has anybody got a better way of setting the top bit of an int in
a vaguely protable manner ?! I spent 5 minutes getting that to work
in gcc just now...]
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]