<<< Date Index >>>     <<< Thread Index >>>

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)