bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warning: comparison is always false due to limited range of data typ


From: Jim Meyering
Subject: Re: warning: comparison is always false due to limited range of data type
Date: Wed, 31 Aug 2005 20:11:03 +0200

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> Is there a patch yet to make gcc suppress that warning?
>
> Sorry, not yet.  Other things are on my plate....
>
>> -      unsigned int n1 = n0 + 1;
>> +      /* FIXME: technically, the type of n1 should be `unsigned int',
>> +     but that evokes an unsuppressible warning from gcc-4.0.1 and
>> +     older.  If gcc ever provides an option to suppress that warning,
>> +     revert to the original type, so that the test in xalloc_oversized
>> +     is once again performed only at compile time.  */
>> +      size_t n1 = n0 + 1;
>
> That doesn't look quite right in general: suppose size_t is narrower
> than unsigned int?  Admittedly it's a theoretical problem, but we
> might as well do it right if it's easy.

Theoretical?
Is it really permitted to have sizeof (size_t) < sizeof (unsigned int)?
Sounds pretty darn perverted, and I'll bet it would make lots of code break.

> Also, I'd rather not penalize all compilers just because GCC is busted.

I understand the point, but wonder if this `penalty'
is even measurable, in practice.

> Personally I'd rather leave the code alone and filter out the messages
> some other way.  But if they really bother you how about this instead?

The offending warning breaks coreutils' `make distcheck' rule.

>    #if __GNUC__
>    # include "size_max.h"
>    #endif
>    ...
>    #if __GNUC__ && UINT_MAX < SIZE_MAX
>        /* FIXME comment, as above.  */
>        size_t n1 = n0 + 1;
>    #else
>        unsigned int n1 = n0 + 1;
>    #endif
>
> That way, non-GCC compilers can have the improved performance.
>
> This will cause quotearg to depend on the size_max module, but that's
> a lightweight module so it should be OK.

The cure, with all of those #if's, is looking worse than the disease.
You're welcome to make that change in gnulib, but perhaps it'd be
better just to let coreutils and gnulib diverge on this particular
file until gcc is fixed.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]