From: Paul Eggert <eggert@cs.ucla.edu>
To: "Jan Djärv" <jan.h.d@swipnet.se>
Cc: 9025@debbugs.gnu.org, bug-gnulib <bug-gnulib@gnu.org>
Subject: bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.
Date: Sat, 09 Jul 2011 03:01:17 -0700 [thread overview]
Message-ID: <4E1826ED.9020602__27152.0647955642$1310205749$gmane$org@cs.ucla.edu> (raw)
In-Reply-To: <4E16D91E.4030108@swipnet.se>
[Following up <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9025>
and cc'ing to bug-gnulib:]
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.
Thanks for reporting this. I assume that intmax_t is 'long long'
whereas int64_t is 'long'? If not, what are those two types defined
to in the system? and by gnulib?
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
+#ifndef UINTMAX_MAX
#undef uintmax_t
#if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1
typedef unsigned long long int gl_uintmax_t;
@@ -291,6 +298,7 @@ typedef unsigned long long int gl_uintmax_t;
typedef unsigned long int gl_uintmax_t;
# define uintmax_t gl_uintmax_t
#endif
+#endif
/* Verify that intmax_t and uintmax_t have the same size. Too much code
breaks if this is not the case. If this check fails, the reason is likely
@@ -431,8 +439,8 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
/* 7.18.2.5. Limits of greatest-width integer types */
+#ifndef INTMAX_MAX
#undef INTMAX_MIN
-#undef INTMAX_MAX
#ifdef INT64_MAX
# define INTMAX_MIN INT64_MIN
# define INTMAX_MAX INT64_MAX
@@ -440,13 +448,15 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
# define INTMAX_MIN INT32_MIN
# define INTMAX_MAX INT32_MAX
#endif
+#endif
-#undef UINTMAX_MAX
+#ifndef UINTMAX_MAX
#ifdef UINT64_MAX
# define UINTMAX_MAX UINT64_MAX
#else
# define UINTMAX_MAX UINT32_MAX
#endif
+#endif
/* 7.18.3. Limits of other integer types */
next prev parent reply other threads:[~2011-07-09 10:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-08 10:17 bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion Jan Djärv
2011-07-09 10:01 ` Paul Eggert [this message]
[not found] <4E1826ED.9020602@cs.ucla.edu>
2011-07-09 10:27 ` Bruno Haible
2011-07-09 11:18 ` Jan Djärv
[not found] ` <201107091227.03099.bruno@clisp.org>
2011-07-09 11:25 ` Jan Djärv
2011-07-09 22:06 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='4E1826ED.9020602__27152.0647955642$1310205749$gmane$org@cs.ucla.edu' \
--to=eggert@cs.ucla.edu \
--cc=9025@debbugs.gnu.org \
--cc=bug-gnulib@gnu.org \
--cc=jan.h.d@swipnet.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.