More platforms have similar bugs, and in the case of glibc on s390,
the bug is in SIZE_MAX instead of SSIZE_MAX.
* doc/posix-headers/stdint.texi (stdint.h): Document the bugs.
* doc/posix-headers/limits.texi (limits.h): Document the bugs.
Signed-off-by: Eric Blake <eblake@redhat.com>
+2016-07-13 Eric Blake <eblake@redhat.com>
+
+ doc: mention glibc, OS X, Cygwin [S]SIZE_MAX buglet
+ * doc/posix-headers/stdint.texi (stdint.h): Document the bugs.
+ * doc/posix-headers/limits.texi (limits.h): Document the bugs.
+
2016-07-13 Paul Eggert <eggert@cs.ucla.edu>
doc: mention glibc SSIZE_MAX buglet
@item
The macro @code{SSIZE_MAX} has the wrong type,
albeit with the correct value:
-glibc 2.24.
+32-bit glibc 2.24 (on some architectures), Cygwin 2.5.2.
@item
The macro @code{SSIZE_MAX} is not defined on some platforms:
MSVC 9.
@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}.