On 10/13/2016 06:36 AM, Eric Blake wrote:
That's a bug in s390's system headers.  Gnulib should be taught to work
around it.


Although this bug was reported fixed in glibc 2.20; see

https://sourceware.org/bugzilla/show_bug.cgi?id=16712

the Gnulib manual says the bug is still in glibc 2.24; see gnulib/doc/posix-headers/stdint.texi. Is the Gnulib manual correct? If so, why didn't the earlier glibc patch fix the bug?

Anyway, I installed into Gnulib the attached patch, which I hope works around the bug. I can't easily test this, so please give it a try. And if you can think of a way to test whether SIZE_MAX has the correct type on pre-C11 compilers that lack __typeof__, please let me know.

From df544bd79a83880cc3287d43c5be1719e1ca2ccf Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 13 Oct 2016 11:16:40 -0700
Subject: [PATCH] stdint: port SIZE_MAX to glibc s390

Problem reported by Eric Blake in:
http://lists.gnu.org/archive/html/bug-gnulib/2016-10/msg00031.html
* doc/posix-headers/stdint.texi (stdint.h): Document the fix.
* m4/stdint.m4 (gl_STDINT_H): Check that SIZE_MAX has the
correct type, if possible.
---
 ChangeLog                     |  9 +++++++++
 doc/posix-headers/stdint.texi |  8 ++++----
 m4/stdint.m4                  | 11 ++++++++++-
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 070e498..89ba80f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2016-10-13  Paul Eggert  <eggert@cs.ucla.edu>
+
+	stdint: port SIZE_MAX to glibc s390
+	Problem reported by Eric Blake in:
+	http://lists.gnu.org/archive/html/bug-gnulib/2016-10/msg00031.html
+	* doc/posix-headers/stdint.texi (stdint.h): Document the fix.
+	* m4/stdint.m4 (gl_STDINT_H): Check that SIZE_MAX has the
+	correct type, if possible.
+
 2016-10-13  Daniel Richard G.  <skunk@iSKUNK.ORG>
 
 	getprogname: port to IBM z/OS
diff --git a/doc/posix-headers/stdint.texi b/doc/posix-headers/stdint.texi
index 2cc083c..d5ca3c2 100644
--- a/doc/posix-headers/stdint.texi
+++ b/doc/posix-headers/stdint.texi
@@ -34,6 +34,10 @@ constant macros such as @code{INTMAX_C}, and one must define
 @code{__STDC_LIMIT_MACROS} to make visible the definitions of limit
 macros such as @code{INTMAX_MAX}.
 @item
+The macro @code{SIZE_MAX} has the wrong type,
+albeit with the correct value:
+32-bit glibc 2.24 (on s390 architecture), Mac OS X 10.7.
+@item
 Macros like @code{INTMAX_WIDTH} are not defined on some platforms:
 glibc 2.24, many others.
 @end itemize
@@ -48,10 +52,6 @@ so public header files should avoid these types.
 @item
 Macros are used instead of typedefs.
 @item
-The macro @code{SIZE_MAX} has the wrong type,
-albeit with the correct value:
-32-bit glibc 2.24 (on s390 architecture), Mac OS X 10.7.
-@item
 Some C preprocessors mishandle constants that do not fit in @code{long int}.
 For example, as of 2007, Sun C mishandles @code{#if LLONG_MIN < 0} on
 a platform with 32-bit @code{long int} and 64-bit @code{long long int}.
diff --git a/m4/stdint.m4 b/m4/stdint.m4
index fa6f103..05b6ab7 100644
--- a/m4/stdint.m4
+++ b/m4/stdint.m4
@@ -1,4 +1,4 @@
-# stdint.m4 serial 47
+# stdint.m4 serial 48
 dnl Copyright (C) 2001-2016 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -154,6 +154,15 @@ uintptr_t h = UINTPTR_MAX;
 intmax_t i = INTMAX_MAX;
 uintmax_t j = UINTMAX_MAX;
 
+/* Check that SIZE_MAX has the correct type, if possible.  */
+#if 201112 <= __STDC_VERSION__
+int k = _Generic (SIZE_MAX, size_t: 0);
+#elif (2 <= __GNUC__ || defined __IBM__TYPEOF__ \
+       || (0x5110 <= __SUNPRO_C && !__STDC__))
+extern size_t k;
+extern __typeof__ (SIZE_MAX) k;
+#endif
+
 #include <limits.h> /* for CHAR_BIT */
 #define TYPE_MINIMUM(t) \
   ((t) ((t) 0 < (t) -1 ? (t) 0 : ~ TYPE_MAXIMUM (t)))
-- 
2.7.4

Reply via email to