bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

[Bruno Haible]

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>