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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list