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 Wed, Feb 20, 2013 at 11:00:02AM -0500, Christopher Faylor wrote:
>On Wed, Feb 20, 2013 at 04:42:02PM +0100, 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
>>>>>
>>>>> #ifndef __ssize_t_defined
>>>>> # ifdef __SIZEOF_SIZE_T__
>>>>> #  if defined (__SIZEOF_INT__) && __SIZEOF_SIZE_T__ == __SIZEOF_INT__
>>>>> typedef int ssize_t;
>>>>> #  else
>>>>> typedef long ssize_t
>>>>> #  endif
>>>>> # elif defined(__INT_MAX__) && defined(__LONG_MAX__) && __LONG_MAX__ == __INT_MAX__
>>>>> typedef int _ssize_t;
>>>>> # else
>>>>> typedef long _ssize_t;
>>>>> # endif
>>>>> #endif
>>>>>
>>>>>
>>>>> 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:
>
>FWIW (and maybe already has already done this research) Linux defines
>"__WORDSIZE" and "__WORDSIZE_COMPAT32" and then defines __SQUAD_TYPE,
>__UQUAD_TYPE, __SWORD_TYPE, etc.  ssize_t, ssize_t and others are based
>on those __WORDSIZE.  This implementation seems fairly clean to me.

Sorry.  That was garbled.

__SWORD_TYPE and others are defined based on __WORDSIZE.  ssize_t and
size_t are then defined using __SWORD_TYPE and __UWORD_TYPE.

cgf


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