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

["Jan Djärv" <jan.h.d@swipnet.se>]

Bruno Haible skrev 2011-07-09 12.27:
> 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.

Outside Emacs is hard, since I don't know what code uses gnulib or how to use 
it standalone.

>
> 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?
>

See reply to Paul.
Basically intmax_t is long and int64_t is long long.  Same size though.

For example:

intmax_t x;
...
printf ("%jd", x);

gives a compiler warning:

warning: format ‘%jd’ expects type ‘intmax_t’, but argument 2 has type ‘int64_t’

The naive fix is to cast x:

printf ("%jd", (intmax_t)x);

but that don't work because intmax_t is a define to int64_t.

	Jan D.

> 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