This is the mail archive of the newlib@sourceware.org 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 16:42, Ralf Corsepius wrote:
> On 02/20/2013 04:17 PM, Corinna Vinschen wrote:
> >On Feb 20 16:08, Ralf Corsepius wrote:
> >>On 02/20/2013 03:14 PM, Corinna Vinschen wrote:
> >>>Hi Yaakov,
> >>>
> >>>On Feb 20 03:23, Yaakov (Cygwin/X) wrote:
> >>>>I just discovered an issue resulting from this commit:
> >>>>
> >>>>2002-06-27  Jeff Johnston  <jjohnstn@...>
> >>>>
> >>>>         * libc/include/sys/_types.h: Define _ssize_t as int if int is
> >>>>         32-bits, otherwise define it as long.
> >>>>
> >>>>On x86_64-cygwin (as on Linux), int is still 32 bits, but size_t is a
> >>>>64bit unsigned long and ssize_t should be as large but signed.
> >>>>Possible patch for newlib attached; corresponding patches for
> >>>>cygwin-64bit-branch on cygwin-patches@.
> >>>
> >>>Thanks for the patch.  I'm just wondering if ssize_t shouldn't ideally
> >>>be based on size_t, at least when using GCC.  GCC has a predefined
> >>>__SIZEOF_SIZE_T__ macro.
> >>>
> >>>What I'm thinking of is something like
> >>>[...]
> >>>Does that make sense?
> >>
> >>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.
> >
> >Do you have a code suggestion then?
> 
> Unfortunately no.
> 
> So far, the best I have been able to come up with for RTEMS, was a
> pretty unpleasant, error prone and lacking generality preprocessor
> cascade:
> 
> ATM, it looks like this:
> <...>
> > GCC doesn't define ssize_t
> >by itself,
> Right, but GCC (IIRC, since 4.4) defines size_t (__SIZE_T_TYPE__)

That's what I pasted in my previous mail.

> and also comes with pretty aggressive fprintf-format strings checks
> related to [s]size_t.
> 
> That said, IMO, in an ideal world, GCC also would define a
> corresponding __SSIZE_T_TYPE__.

Unfortunately we're not living in an ideal world.  That said, I'm
willing to go with the obvious as I outlined above. Since size_t is
*likely* defined as int if int == long, and defined as long if int <
long, this should match most cases.  Oh, and then there are the
potential LLP64 systems which define sizeof size_t == sizeof long long.
An additional elif would catch that:

#  if defined (__SIZEOF_INT__) && __SIZEOF_SIZE_T__ == __SIZEOF_INT__
typedef int ssize_t;
#  elif defined (__SIZEOF_LONG__) && __SIZEOF_SIZE_T__ == __SIZEOF_LONG__
typedef long ssize_t
#  else
typedef long long ssize_t;
#  endif

...but I don't know if it's worth the effort since no LLP64 system
(==Windows) uses newlib.  And nothing speaks against overriding the
definition in a machine-specific header.


Corinna

-- 
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]