On Solaris 9 with gcc 4.6.4, it is surprising to see that the test program
(from stdint.m4) fails and thus gnulib provides an <stdint.h> replacement,
but the original <stdint.h> does not actually exhibit the bug which the
test program reports.
More precisely, config.log reports this outcome of the test program:
configure:22117: checking whether stdint.h conforms to C99
configure:22292: gcc -O2 -c -g -O2 -I/home/haible/prefix-sparc32/include -Wall
-D_REENTRANT conftest.c >&5
conftest.c:246:52: error: expected expression before '?' token
conftest.c:246:52: error: bit-field 'check_uintptr' width not an integer
constant
So it's this statement (in a struct):
int check_uintptr: (uintptr_t) -1 == UINTPTR_MAX ? 1 : -1;
But the program
=============================================================
#include <stdint.h>
struct s {
int check_uintptr: (uintptr_t) -1 == UINTPTR_MAX ? 1 : -1;
};
=============================================================
compiles fine!
What's going on? There is a system include file
/usr/include/sys/int_limits.h
which overwrites INTPTR_MAX and UINTPTR_MAX with empty values:
#define INTPTR_MAX
#define UINTPTR_MAX
and this system include file gets included by <limits.h> and <inttypes.h>.
As a consequence the following programs fail to compile:
=============================================================
#include <stdint.h>
#include <limits.h>
struct s {
int check_uintptr: (uintptr_t) -1 == UINTPTR_MAX ? 1 : -1;
};
=============================================================
#include <stdint.h>
#include <inttypes.h>
struct s {
int check_uintptr: (uintptr_t) -1 == UINTPTR_MAX ? 1 : -1;
};
=============================================================
But the following sequences of includes do define UINTPTR_MAX correctly:
#include <stdint.h>
#include <limits.h>
#include <stdint.h>
#include <inttypes.h>
#include <stdint.h>
#include <limits.h>
#include <stdint.h>
#include <limits.h>
#include <limits.h>
#include <stdint.h>
#include <inttypes.h>
So, the reason why <stdint.h> is found to be nonconforming by the stdint.m4
test is that it happens to include <limits.h> at the "right" moment.
Something worth documenting:
2016-12-10 Bruno Haible <br...@clisp.org>
stdint: Update doc about Solaris 9.
* doc/posix-headers/stdint.texi: Add info about Solaris 9.
diff --git a/doc/posix-headers/stdint.texi b/doc/posix-headers/stdint.texi
index d5ca3c2..03542c1 100644
--- a/doc/posix-headers/stdint.texi
+++ b/doc/posix-headers/stdint.texi
@@ -24,6 +24,11 @@ The values of @code{INT8_MAX}, @code{UINT8_MAX} etc. are not
usable in
preprocessor expressions on some platforms:
HP-UX 11.23.
@item
+The values of @code{INTPTR_MAX} and @code{UINTPTR_MAX}, although correctly
+defined in @code{<stdint.h>}, are replaced by empty values when
+@code{<limits.h>} or @code{<inttypes.h>} gets included later on some platforms:
+Solaris 9 with GCC 4.5 or newer.
+@item
The macros @code{WCHAR_MIN} and @code{WCHAR_MAX} are not defined in
@code{<stdint.h>} (only in @code{<wchar.h>}) on some platforms:
Dragonfly, BSDI.
