[PATCH 64bit] ssize_t

[Ralf Corsepius]

On 02/20/2013 05:06 PM, Corinna Vinschen wrote:
> 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

Sorry, I think, I did not communicate my point accurately.

Let me try again:

GCC doesn't apply a size-based logic to define size_t, but applies 
hard-coded predefined types for size_t, likely based on historic 
per-target conventions.

I.e. any type-size based logic will sometimes fail:

E.g. for targets with sizeof(size_t) == sizeof(int) == sizeof(long). on 
some targets GCC uses "typedef unsigned int size_t" and on other targets 
GCC uses "typedef unsigned long size_t".

Now, if you choose "typedef int ssize_t" on targets, which use "typedef 
long size_t", GCC will raise warnings related to fprintfs.

Ralf