mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (08/06/87)
[I'm very tempted to cross-post this to comp.lang.c, but I won't. They
see it every few weeks, and would quite rightly flame me for bringing
it up again.]
In article <3199@zen.berkeley.edu> waterman@cory.Berkeley.EDU.UUCP (T.S. Alan Waterman) writes:
<Mike, the deal with this problem is this:
<
< if (ptr == 0) compares the pointer with an INT, which is gonna be 16 bits.
In that case, the compiler is doing the wrong thing. Quoting K&R, page
190, section 7.7:
A pointer to which 0 has been assigned is guaranteed not to
point to any object, and will appear to be equal to 0 ...
They don't say so, but anyone reasonable would assume that a pionter
which had not been assigned the value 0 will *not* compare equal to 0.
Note, that's "0", not "0L" or "(my_favorite_type *) 0".
From dpANS, page 30, section 3.2.2.3:
An integral constant with the value 0, or such an expression
cast to type void *, is called a null pointer constant. If a
null pointer constant is assigned to or COMPARED FOR EQUALITY
[emphasis mine - mwm] to a pointer, the constant is converted
to a pointer of that type.
Once again, that's "0", not "0L".
<In short, the error message is correct. You are being rightly warned the the
<compiler is about to do exactly what you told it to, and not really what
<you wanted to do.
Yes, the warning is correct. It is not doing what I wanted it to do.
But it is not doing what I told it to do. I gave instructions that a
compiler for C will interpret to mean "decide if this pointer is a
pointer to zero."
It's not clear what Manx C is doing. It could be
1) comparing the pointer to a 32-bit zero.
2) comparing the low order 16 bits of the pointer to zero.
3) compare the pointer to the zero + whatever happens to be in
memory adjacent to it.
Well, it could also be doing what GNU C does with #pragma, or
something really strange. But those three are the only rational
actions. And three isn't very rational. Since one is the right thing
to do, I assume that it's doing two.
This seems to be something that C compiler writers don't seem to be
able to get right - especially on the eighty-eightysux family. So
not getting it right doesn't qualify as a major flaw.
Continuing to defend it as correct in the face of clear evidence to
the contrary is a major flaw. I'll follow the same path that
Guy Harris, Chris Torek and Henry Spencer followed under those
conditions.
<mike
--
The weather is here, I wish you were beautiful. Mike Meyer
My thoughts aren't to clear, but don't run away. mwm@berkeley.edu
My girlfriend's a bore, my job is to dutiful. ucbvax!mwm
Hell nobodies perfect, would you like to play? mwm@ucbjade.BITNETcjp@vax135.UUCP (Charles Poirier) (08/08/87)
In article <4613@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >This seems to be something that C compiler writers don't seem to be >able to get right - especially on the eighty-eightysux family. So >not getting it right doesn't qualify as a major flaw. > >Continuing to defend it as correct in the face of clear evidence to >the contrary is a major flaw.... Fine, I'm content to consider Manx's failure to notice the requisite special case of pointer compared to 0, as a minor flaw. One that is largely fixed by redefining NULL in the Manx include file. Of course code that makes explicit comparison to 0 rather than NULL will still lose, but that's no big deal, just edit those 0's to NULLs. Gee whiz, I try to give a helpful bug fix and people start complaining all the harder about the bug I just fixed. I didn't make any sweeping statement about C standards, just noted an obvious fixup for Manx users. It needn't even touch the source code, just an include, so what's the beef with respect to standards? Take it for what it's worth, if you don't need it you can ignore it. Can we please drop the C standards debate from the Amiga group? Thanks. -- Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp "Docking complete... Docking complete... Docking complete..."