Re: c/10040: Incorrect warning message for bit fields

[James L Peterson <peterson at austin dot ibm dot com>]

Falk Hueffner wrote:

> On 12 Mar 2003 peterson at austin dot ibm dot com wrote:
>
> >     int _v: 1;
> >     if ((*tlb)._hi._v == 1)
> >
> > warning: comparison is always 0 due to width of bit-field
>
> The warning seems 100% correct to me. The comparison *is* always 0.
>
> > In trying to explain the problem, I'm beginning to see that this error
> > message is a result of the bit field being an "int" (signed) rather
> > than "unsigned int".  In which case, maybe the problem is best
> > addressed by a different warning message -- "bit field too small for
> > value and sign bit; consider unsigned type for field"
>
> That's too much guessing for my taste. The declaration might be just what
> was intended, and only the comparison is bogus. At most I'd consider
> "warning: comparison is always 0 due to width and signedness of
> bit-field".

I've gone back over the C spec and I understand (now) what gcc is
doing.  I would really suggest that the warning message be changed
to indicate that the compiler has found a signed field, and since one
bit is kept as a sign, there is not room for the value.

I've talked to a number of experienced C programmers, and even some
friends who teach C (and C++ and Java) at the University.  Everyone
agrees that the expectation is that a bit field of size 1 will hold only
two values: 0 and 1.  It's only after the signed/unsigned aspect is
explained that they understand the reason for the error message.

Since the purpose of the warning message is to try to convey
that there is a problem, and what the problem is, it would be clearer
if the warning message was explicit about the need to store a sign
bit and the value.  Since the code already separates the signed and
unsigned case, it requires only changing the one warning message.

(In general, it is difficult to deal with systems that generate the
exact same error message in more than one place.  If the message
is generated, and you don't understand exactly what the problem is,
even looking at the code may not help.  In this case, not knowing the
details of the code, I couldn't even isolate which of the two error messages

was being generated without tagging them, recompiling gcc and running
it so I could tell what, exactly, was the problem.)

jim