stdint: update doc about Solaris 9

[Bruno Haible]

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  <address@hidden>

        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
address@hidden<limits.h>} or @code{<inttypes.h>} gets included later on some 
platforms:
+Solaris 9 with GCC 4.5 or newer.
address@hidden
 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.