On Jul 13 15:02, Eric Blake wrote: > POSIX requires that SSIZE_MAX have the same type as ssize_t, but > on 32-bit, we were defining it as a long even though ssize_t > resolves to an int. It also requires that SSIZE_MAX be usable > via preprocessor #if, so we can't cheat and use a cast. > > If this were newlib, I'd have had to hack _intsup.h to probe the > qualities of size_t (via gcc's __SIZE_TYPE__), similar to how we > already probe the qualities of int8_t and friends, then cross our > fingers that ssize_t happens to have the same rank (most systems > do, but POSIX permits a system where they differ such as size_t > being long while ssize_t is int). Unfortunately gcc gives us > neither __SSIZE_TYPE__ nor __SSIZE_MAX__. On the other hand, our > limits.h is specific to cygwin, we can just shortcut to the > correct results rather than being generic to all possible ABI. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > --- > winsup/cygwin/include/limits.h | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/winsup/cygwin/include/limits.h b/winsup/cygwin/include/limits.h > index 2083e3e..cf3c8d0 100644 > --- a/winsup/cygwin/include/limits.h > +++ b/winsup/cygwin/include/limits.h > @@ -128,9 +128,17 @@ details. */ > #undef ULLONG_MAX > #define ULLONG_MAX (LLONG_MAX * 2ULL + 1) > > -/* Maximum size of ssize_t */ > +/* Maximum size of ssize_t. Sadly, gcc doesn't give us __SSIZE_MAX__ > + the way it does for __SIZE_MAX__. On the other hand, we happen to > + know that for Cygwin, ssize_t is 'int' on 32-bit and 'long' on > + 64-bit, and this particular header is specific to Cygwin, so we > + don't have to jump through hoops. */ > #undef SSIZE_MAX > +#if __WORDSIZE == 64 > #define SSIZE_MAX (__LONG_MAX__) > +#else > +#define SSIZE_MAX (__INT_MAX__) > +#endif > > > /* Runtime Invariant Values */
Looks good, please apply. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
