On Wed, 27 Feb 2002, Jon Wilson wrote:
>
> Hi David et al,
>
> There's been a lot of discussion between myself and my colleagues
> about the warnings generated by Splint over such things as this:*
>
> unsigned short a = 1 ;
> long b = 2 ;
>
> if ( a < b ) {
> return FALSE ;
> }
>
> blah.c(10): Operands of < have incompatible types (unsigned short int, long int): a
>< b
> To ignore signs in type comparisons use +ignoresigns
>
> Now while this is clearly true, we would argue it's also harmless IFF
> we can assume an ANSI compiler.
>
The question is what should "harmless" mean? Splint considers lots of
things that are perfectly well defined C code to be worthy of warnings
since they may reveal program bugs. In this case, you are corred that the
integer conversion rules mean the code almost certainly means what the
programmer intended.
I think in this case, what is needed is more precise flags, so you can
turn off "harmless" sign incompatability warnings. We should have a flag
list "relaxquals" to control warnings about sign issues that are less
likely to reveal program bugs and ones where the behavior is misleading.
> The second edition of K&R says this:
>
> A6.1 Integral Promotion
>
> A character, a short integer, or an integer bit-field, all either
> signed or not, or an object of enumeration type, may be used in an
> expression whenever an integer may be used. If an int can represent
> all of the values of the original type, then the value is converted to
> int, otherwise the value is converted to unsigned int. This process is
> called integral promotion.
>
> Since all uint16 values are representable in an int32, I reckon this
> warning is not justified in this case. We'd like to turn +ignoresigns
> back on, because of course there are many times when it's telling us
> something important!
>
> Cheers,
>
> Jon
>
> *With myself as the Splint evangelist and many others just wanting to
> shut it up :->
>
Its a tough job, I know, but keep on evangelizing!
--- Dave
