Re: Little code cleanup
On 2008-03-08 20:15:00 -0500, Derek Martin wrote:
> In reading this and re-reading the preceding messages in the thread, I
> got logically turned around a bit. But despite K&R, it doesn't seem
> particularly unintuitive that the compiler would warn in that case...
> It may well be allowed, but still they are not the same type. It
> seems to me there are good cases for both arguments (warning and not
> warning).
Just an additional note... The warning was not because the types were
different (BTW, one often compares pointers to the integer constant 0
by writing "if (p)" or "if (p == NULL)" on implementations where NULL
is the integer 0, and this has never been a problem).
Consider the following program:
int main (void)
{
char a[1], *b;
b = a;
if (a == 0)
return 1;
else if (a == (void *) 0)
return 2;
else if (b == 0)
return 3;
else if (b == (void *) 0)
return 4;
return 0;
}
gcc gives a warning only for the test "a == 0":
tst.c: In function 'main':
tst.c:5: warning: the address of 'a' will never be NULL
So, the problem is not the mismatched types, otherwise one would
have a warning for b == 0. So, the warning seems to be about the
comparison <array_type> and the null pointer constant, but this
doesn't explain why one doesn't get a warning for a == (void *) 0.
Also note that warnings are only choices by the compiler and the
C standard allows any warning (diagnostic message). This is just
a matter of quality of implementation.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)