This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 64bit] ssize_t

On Feb 20 10:00, Eric Blake wrote:
> On 02/20/2013 09:56 AM, Corinna Vinschen wrote:
> > On Feb 20 09:36, Eric Blake wrote:
> >> On 02/20/2013 09:30 AM, Schwarz, Konrad wrote:
> >>
> >>>>>> GCC requires exact symmetry of types between ssize_t and size_t.
> >>>>>> I.e. checking for sizes of types is not sufficient for [s]size_t.
> >>
> >>>
> >>> Pardon me, but would an approach similar to the following work?
> >>>
> >>> # include <limits.h>
> >>>
> >>> typedef int
> >>> # if USHRT_MAX == __SIZE_MAX__
> >>> 	short
> >>> # elif UINT_MAX == __SIZE_MAX__
> >>
> >> No, because when size_t and long are 4 bytes, UINT_MAX == LONG_MAX, but
> >> that's a case where we want ssize_t to be long, not int.
> > 
> > Do we really?  I thought that int is preferred if int == long.
> I guess it boils down to: can we guarantee that if 'int', 'long', and
> 'size_t' are all the same size, then 'size_t' was based on 'int' instead
> of 'long'?

Guarantee?  No.  We can only make an educated guess.  Just for testing
I tried it on i686-pc-cygwin and i686-w64-mingw32 and both return

  #define __SIZE_TYPE__ unsigned int

If the educated guess doesn't work, a machine dependent override will
be necessary.

And I agree with Ralf.  In the long run, GCC should really define
__SSIZE_TYPE__ and friends...


Corinna Vinschen
Cygwin Maintainer
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]