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

[Jan Djärv]

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