Jan Djärv writes: > > Somewhere in gnulib, intmax_t gets defined to int64_t thus causing > > compiler warnings and general confusion (the code says intmax_t but is > > really int64_t). AFAIK, all versions of OSX have intmax_t.
Please provide a reproducible test case, preferrably outside Emacs. Also, I don't understand what's the problem: intmax_t must be 64-bit on MacOS X. No compiler supports 128-bit integers, AFAIK. Can you explain? Paul Eggert wrote: > Which compiler and OS version are you using? > > Does the following (untested) patch to lib/stdint.in.h fix your problem? > > diff --git a/lib/stdint.in.h b/lib/stdint.in.h > index c44401f..0dd60b9 100644 > --- a/lib/stdint.in.h > +++ b/lib/stdint.in.h > @@ -270,6 +270,11 @@ typedef unsigned long int gl_uintptr_t; > /* Note: These types are compiler dependent. It may be unwise to use them in > public header files. */ > > +/* If the system defines INTMAX_MAX, assume that intmax_t works, and > + similarly for UINTMAX_MAX and uintmax_t. This avoids problems with > + assuming one type where another is used by the system. */ > + > +#ifndef INTMAX_MAX > #undef intmax_t > #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1 > typedef long long int gl_intmax_t; > @@ -280,7 +285,9 @@ typedef long long int gl_intmax_t; > typedef long int gl_intmax_t; > # define intmax_t gl_intmax_t > #endif > +#endif Untested patches are OK in simple areas. But in complex areas like stdint.in.h I would really like to understand the problem before applying any patch. That means, provide a reproducible sample (including all details about OS, compiler, compiler options), and show the preprocessing result (output of "$CC -E" or - even better - "$CC -E -dD") of the code that gives warnings. Bruno -- In memoriam Báb <http://en.wikipedia.org/wiki/Báb>
