Re: size_max

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> How about this?  The patch was discussed and revised a few times some
> months ago.  Nobody complained after the last patch was posted.  I'll
> install this on Sunday, unless someone complains.

It seems a bit odd for you to list Bruno as the maintainer, if broke
out the module.  Perhaps you should change the maintainer to being
Bruno and yourself?  Or Bruno and "all"?

Also, while we're on the subject of size_max.m4, I have a pedantic
point: its use of ~(size_t)0 isn't portable in general.  For example,
if size_t is narrower than int, then ~(size_t)0 might evaluate to -1,
which isn't correct.  Furthermore there are missing parentheses in the
'Shouldn't happen' case.  I don't think this is much of a practical
issue, but in general we should encourage the use of (size_t) -1
rather than ~(size_t)0 because it's better to be safe than sorry.

Here's a proposed patch.

2005-06-24  Paul Eggert  <address@hidden>

        * size_max.m4 (gl_SIZE_MAX): ~(size_t)0 -> (size_t) -1,
        since the latter works even if size_t is narrower than int.

--- size_max.m4 2005-01-18 05:07:56 -0800
+++ /tmp/size_max.m4    2005-06-24 11:01:41 -0700
@@ -26,9 +26,9 @@ Found it
     dnl than the type 'unsigned long'.
     dnl The _AC_COMPUTE_INT macro works up to LONG_MAX, since it uses 'expr',
     dnl which is guaranteed to work from LONG_MIN to LONG_MAX.
-    _AC_COMPUTE_INT([~(size_t)0 / 10], res_hi,
+    _AC_COMPUTE_INT([((size_t) -1) / 10], res_hi,
       [#include <stddef.h>], result=?)
-    _AC_COMPUTE_INT([~(size_t)0 % 10], res_lo,
+    _AC_COMPUTE_INT([((size_t) -1) % 10], res_lo,
       [#include <stddef.h>], result=?)
     _AC_COMPUTE_INT([sizeof (size_t) <= sizeof (unsigned int)], fits_in_uint,
       [#include <stddef.h>], result=?)
@@ -48,7 +48,7 @@ Found it
       fi
     else
       dnl Shouldn't happen, but who knows...
-      result='~(size_t)0'
+      result='((size_t) -1)'
     fi
   fi
   AC_MSG_RESULT([$result])