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

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> It will take a while for this fix to propagate, though.  In the
> meantime, why not modify the definition of xalloc_oversized(n,s) to
> always return 0 if if s is a constant and if the size of n is such
> that the comparison cannot possibly fail.  Something like this?
> (completely untested):
>
> 2005-06-22  Paul Eggert  <address@hidden>
>
>       * xalloc.h: Work around a bogus GCC 4.0.0 warning "comparison is always
>       false due to limited range of data type".  Problem reported by
>       Oskar Liljeblad.
>       (xalloc_lt, xalloc_lt_always_false): New macros.
>       (xalloc_oversized): Use them.
>
> --- xalloc.h  2005-05-14 01:02:58 -0700
> +++ /tmp/xalloc.h     2005-06-22 13:53:19 -0700
> @@ -56,6 +56,22 @@ void *x2nrealloc (void *p, size_t *pn, s
>  void *xmemdup (void const *p, size_t s);
>  char *xstrdup (char const *str);
>
> +/* Work around a bogus GCC 4.0.0 warning "comparison is always false
> +   due to limited range of data type".  */
> +
> +# define xalloc_lt(m, n) (! xalloc_lt_always_false (m, n) && (m) < (n))
> +# if __GNUC__ < 4
> +#  define xalloc_lt_always_false(a, b) 0
> +# else
> +#  ifndef CHAR_BIT
> +#   include <limits.h>
> +#  endif
> +#  define xalloc_lt_always_false(m, n)                       \
> +     (__builtin_constant_p (m)                               \
> +      && sizeof (n) < sizeof (size_t)                        \
> +      && (size_t) 1 << (sizeof (n) * CHAR_BIT) <= (m))       \
> +# endif

Nice try.  That fixes the problem in quotearg.c, but provokes
new warnings from gcc-4.0.1 (even on 32-bit systems):

  xmalloc.c: In function 'xnmalloc_inline':
  xmalloc.c:49: warning: left shift count >= width of type
  xmalloc.c: In function 'xnrealloc_inline':
  xmalloc.c:74: warning: left shift count >= width of type

It looks like these warnings appear only with -O :-)

Then I realized that we could avoid the shift count trouble
by using TYPE_MAXIMUM (__typeof__ (n)) since this is gcc-4 specific:
(in which case, this part
sizeof (n) < sizeof (size_t)
is probably not necessary, but I left it in anyhow)

Index: lib/xalloc.h
===================================================================
RCS file: /fetish/cu/lib/xalloc.h,v
retrieving revision 1.27
diff -u -p -r1.27 xalloc.h
--- lib/xalloc.h        14 May 2005 07:58:07 -0000      1.27
+++ lib/xalloc.h        23 Jun 2005 07:24:53 -0000
@@ -56,6 +56,23 @@ void *x2nrealloc (void *p, size_t *pn, s
 void *xmemdup (void const *p, size_t s);
 char *xstrdup (char const *str);
 
+/* Work around a bogus GCC 4.0.0 warning "comparison is always false
+   due to limited range of data type".  */
+
+# define xalloc_lt(m, n) (! xalloc_lt_always_false (m, n) && (m) < (n))
+# if __GNUC__ < 4
+#  define xalloc_lt_always_false(a, b) 0
+# else
+#  ifndef CHAR_BIT
+#   include <limits.h>
+#  endif
+#  include "intprops.h"
+#  define xalloc_lt_always_false(m, n)                 \
+     (__builtin_constant_p (m)                         \
+      && sizeof (n) < sizeof (size_t)                  \
+      && TYPE_MAXIMUM (__typeof__ (n)) <= (m))
+# endif
+
 /* Return 1 if an array of N objects, each of size S, cannot exist due
    to size arithmetic overflow.  S must be positive and N must be
    nonnegative.  This is a macro, not an inline function, so that it
@@ -69,7 +86,8 @@ char *xstrdup (char const *str);
    exactly-SIZE_MAX allocations on such hosts; this avoids a test and
    branch when S is known to be 1.  */
 # define xalloc_oversized(n, s) \
-    ((size_t) (sizeof (ptrdiff_t) <= sizeof (size_t) ? -1 : -2) / (s) < (n))
+    xalloc_lt ((size_t) (sizeof(ptrdiff_t) <= sizeof(size_t) ? -1 : -2) / (s), 
\
+              n)
 
 # ifdef __cplusplus
 }

But that didn't help.  All it did was get me back to the
`comparison always fails' warning.  I confirmed that even with

  #define xalloc_lt_always_false(a, b) 1

we'd still get that warning.  So what we really want is a way
to tell gcc that we know what we're doing in a particular
expression (or module or file) so it doesn't emit that particular
warning.

Better still would be an option to tell GCC not to bother us
with warnings in any expression that it is going to optimize away.