Careful. Operands of relational operators undergo "usual arithmetic
conversions," which are value-preserving, so unsigned char and unsigned
short are promoted to int on platforms where int is value-preserving.
Similarly, unsigned int is promoted to long where long is value-preserving,
as I pointed out earlier in this thread. (This wasn't always the case,
see below.)
The problem here, of course, is that if you don't know the widths of the
operands, you can't determine the type of the compare. Change the width
of the operand (to steal some bits in a structure, say) and the signedness
of the comparison changes.
>
> > if there are cases that are not defined in a standard and could vary by
> > compiler/version then we definantly need to have the current version with
> > the type argument.
>
> No, these cases are defined perfectly clearly and have been at least
> since K&R.
K&R 1st Edition and the UNIX 7th Edition C reference manual specify that
unsigned dominates. The "value-preserving" language was crafted for
C89, and appears in K&R, 2nd Edition. C99 introduces the notion of
integer type "rank" to generalize the rules to extended precision types.
Regards,
Bill Rugolsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/