[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes war
bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.
Sat, 09 Jul 2011 13:25:54 +0200
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
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
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.
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.
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
@@ -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. */
#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
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.