Re: stdint_.h incorrectly assumes unsigned of 'int64_t'

[Paul Eggert]

Matthew Woehlke <address@hidden> writes:

> ...which I assume those who have been following my NSK woes will
> immediately spot the flaw in? :-)

Thanks, I installed this patch into gnulib:

2006-11-09  Paul Eggert  <address@hidden>

        * lib/stdint_.h (uintmax_t): Fix typo: int64_t -> uint64_t.
        Problem reported by Matthew Woehlke.

--- lib/stdint_.h       21 Oct 2006 22:10:07 -0000      1.35
+++ lib/stdint_.h       10 Nov 2006 01:03:19 -0000
@@ -230,7 +230,7 @@
 #undef uintmax_t
 #if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1
 # define uintmax_t unsigned long long int
-#elif defined int64_t
+#elif defined uint64_t
 # define uintmax_t uint64_t
 #else
 # define uintmax_t unsigned long int


> (This was stdint_.h from coreutils-6.4, IIRC someone had said that
> should be more recent than patches that went in for NSK?

gnulib has the most-recent copy.

Or are you referring to this patch?

http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00140.html

It's not in gnulib. In
<http://lists.gnu.org/archive/html/bug-gnulib/2006-11/msg00092.html>
Bruno indicated that he'd rather not worry about weird environments
that have 64-bit signed int but not 64-bit unsigned int.  He has a
point, in that a lot of the existing code (more than we probably know
about already) assumes that LLONG_MAX < ULLONG_MAX.

I think that if you want to continue the porting effort we (by which I
mean, mostly, _you_ :-) should probably just come up with the patches
that work for you, and we can worry about integrating them into the
upstream version later.

The simplest thing for you may be to upgrade to Tandem's current
compiler, which doesn't seem to have these problems.

>  Also I'm
> actually trying to build m4 at the moment; should I be cc'ing bugs-m4
> on this stuff?)

m4 uses gnulib, so when they upgrade to the latest gnulib version
they'll get the above patch.  But it doesn't hurt to CC: bug-m4 if
you've run into the problem with m4.