How to silence a particular “pointless comparison of unsigned with zero” warning?

Question

Suppose I have a function like the following:

#define LOWER_BOUND 0
#define UPPER_BOUND 42

int is_value_in_range( some_typedef val)
{
    return ((LOWER_BOU         


        

Answer 1

If some_typedef is not known to be unsigned or signed, I think you're pretty much out of luck.

If you know in advance that some_typedef is unsigned, you could just use

#if LOWER_BOUND > 0
    return ((LOWER_BOUND <= val) && (val <= UPPER_BOUND));
#else
    return ((val <= UPPER_BOUND));
#endif

Or in this case, you could use my preferred version:

    return (val-LOWER_BOUND <= UPPER_BOUND-LOWER_BOUND);

Edit: I'm going to assume if some_typedef is not known to be of particular signedness, then UPPER_BOUND and LOWER_BOUND must both be positive. Otherwise you would have very wacky results from some_typedef getting promoted to unsigned. Thus, you could always safely use:

    return ((uintmax_t)val-LOWER_BOUND <= UPPER_BOUND-LOWER_BOUND);

Answer 2

Rather than trying to silence the warning, why not do something about it and avoid the typedef in the first place? You can make overloads to handle specific cases and by avoiding the masking of warnings your more explicitly declaring that you're handling the cases you're dealing with. In my experience, that tends to force you to test new code instead of masking things which might happen in the future (like suddenly changing data types and then having to deal with values mysteriously failing to lie in expected ranges).

Answer 3

I came up with a pretty simple and straight forward solution. Copying the lower bound to a variable causes the compiler to stop complaining:

#define LOWER_BOUND 0
#define UPPER_BOUND 42

int is_value_in_range( some_typedef val)
{
    some_typedef lowerbound = LOWER_BOUND;

    return ((lowerbound <= val) && (val <= UPPER_BOUND));
}

I expect that in an optimized build, the compiler will still be able to easily get rid of the invariant comparison (I'll have to verify, though).

Answer 4

That's usually controlled by pragmas. For MSVC, you have #pragma warning and for GCC you have diagnostic pragmas (which admittedly don't allow for as fine-grained control over warnings as MSVC, but that's all you have).

Both allow for push/pop mechanics to only change the warnings for a few lines of code.