Simon Hosie
Tue, 12 Dec 2000 10:35:19 -0800
On Tue, 12 Dec 2000, Pete French wrote:
> 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.
Right you are. Thinko' on my part.
It makes me wonder, though. Why would someone do something like that unless
they meant to make it a pointer to an integer and forgot to assign it a
better value later on?
> Im so glad I dont work with PC's...
I would be if I didn't, too. *sigh*
> 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 ?)
That's not actually changing the way 'if' works. ! is shorthand for a
comparison with zero, in a comparison zero will be cast to a pointer, and
when zero is cast to a pointer the compiler has the opportunity to replace
the value with any constant illegal-pointer-value it chooses. That's why
you need to use a zero cast to a pointer in situations where the compiler
can't do it automatically.
This is what happens when you try to standardise a language after it's been
used for too long.
> -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...]
'(INT_MAX - (INT_MAX >> 1))' should work for all the integer representations
that I can think of right now, but for that particular situation you might
as well use INT_MAX (assuming, of course, that int is the same size as a
pointer).
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]