diff options
| author | Joseph Myers <joseph@codesourcery.com> | 2018-02-06 21:38:51 +0000 |
|---|---|---|
| committer | Joseph Myers <joseph@codesourcery.com> | 2018-02-06 21:38:51 +0000 |
| commit | 625fb764b4d9138fe9c2cbffa1b755e8f43f6e06 (patch) | |
| tree | 1bb3e6b56e542c8abfdc4fd092a8102c9ef8650f /posix/bits | |
| parent | 02325d6c3a3eb415556782a7d2cfff589d29493d (diff) | |
| download | glibc-625fb764b4d9138fe9c2cbffa1b755e8f43f6e06.tar glibc-625fb764b4d9138fe9c2cbffa1b755e8f43f6e06.tar.gz glibc-625fb764b4d9138fe9c2cbffa1b755e8f43f6e06.tar.bz2 glibc-625fb764b4d9138fe9c2cbffa1b755e8f43f6e06.zip | |
Correct type of SSIZE_MAX for 32-bit (bug 13575).
Bug 13575 reports that SSIZE_MAX is wrongly defined as LONG_MAX on
32-bit systems where ssize_t is defined as int (which is most 32-bit
systems supported by glibc).
This patch fixes the definition, using a conditional on
__WORDSIZE32_SIZE_ULONG to determine the appropriate type in the
32-bit case. Formally ssize_t need not be the signed type
corresponding to size_t, but as it is for all current glibc
configurations, there is no need for a new macro different from the
one used for defining SIZE_MAX. A testcase is added for both the type
and the value of SSIZE_MAX.
There is a relevant peculiarity in
sysdeps/unix/sysv/linux/s390/bits/typesizes.h:
/* Compatibility with g++ 2.95.x. */
/* size_t is unsigned long int on s390 -m31. */
This has the effect that for GCC 2 for s390, ssize_t does not match
__WORDSIZE32_SIZE_ULONG. I don't think such a conditional on the GCC
version makes sense - to have a well-defined ABI, the choices of
standard types should not depend on the GCC version. It's also the
case that upstream GCC 2.95 did not support s390, and glibc headers
don't in general try to support past development GCC versions - only
actual releases and current mainline development. But whether or not
that GCC 2 case should be removed (with or without a NEWS entry for
such a change), this patch does not result in any changes for s390;
the value is always still LONG_MAX in the s390 case because
__WORDSIZE32_SIZE_ULONG is always defined for 32-bit s390. I don't
think any such oddity in code only active for unofficial or unreleased
old compiler versions should block closing the present bug as fixed
once this patch is in.
Tested for x86_64 and x86, and with build-many-glibcs.py.
[BZ #13575]
* posix/bits/posix1_lim.h: Include <bits/wordsize.h>.
[!SSIZE_MAX && !(__WORDSIZE == 64 || __WORDSIZE32_SIZE_ULONG)]
(SSIZE_MAX): Define to INT_MAX.
* posix/test-ssize-max.c: New file.
* posix/Makefile (tests): Add test-ssize-max.
Diffstat (limited to 'posix/bits')
| -rw-r--r-- | posix/bits/posix1_lim.h | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/posix/bits/posix1_lim.h b/posix/bits/posix1_lim.h index 90066ffae3..18ac47fb2b 100644 --- a/posix/bits/posix1_lim.h +++ b/posix/bits/posix1_lim.h @@ -24,6 +24,7 @@ #ifndef _BITS_POSIX1_LIM_H #define _BITS_POSIX1_LIM_H 1 +#include <bits/wordsize.h> /* These are the standard-mandated minimum values. */ @@ -161,7 +162,14 @@ #ifndef SSIZE_MAX -# define SSIZE_MAX LONG_MAX +/* ssize_t is not formally required to be the signed type + corresponding to size_t, but it is for all configurations supported + by glibc. */ +# if __WORDSIZE == 64 || __WORDSIZE32_SIZE_ULONG +# define SSIZE_MAX LONG_MAX +# else +# define SSIZE_MAX INT_MAX +# endif #endif |