[PATCH 64bit] ssize_t

[Craig Howland]

On 02/20/2013 11:16 AM, Eric Blake wrote:
> On 02/20/2013 08:17 AM, Corinna Vinschen 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.
>> Do you have a code suggestion then?  GCC doesn't define ssize_t
>> by itself, nor in stddef.h except for BeOS.  And the only predefines
>> helping us are
>>
>>    #define __SIZE_MAX__ 18446744073709551615UL
>>    #define __SIZEOF_INT__ 4
>>    #define __SIZEOF_LONG__ 8
>>    #define __SIZEOF_SIZE_T__ 8
>>    #define __SIZE_TYPE__ long unsigned int
> There's the key.  But how to make gcc tell us the corresponding signed
> type?  Can we write something that relies on __builtin_types_compatible_p?
It seems that if a configuration test were added that this could be made to 
work.  I made a quick example check based on a GCC manual example for the 
__builtin_choose_expr function which will either pass or fail compilation as the 
target type is adjusted.  It would be pretty clunky, probably, but could be 
done.  (This was a trial test under Linux, so I just tossed in sys/types.h o get 
size_t.)

#include <sys/types.h>

void
typeof_size_t(void)
{
#define foo(x) \
         __builtin_choose_expr ( \
                 __builtin_types_compatible_p (x, size_t), \
                 1, \
                         /* The void expression results in a compile-time error \
                         *when assigning the result to something. */ \
                         (void)0)
int  i=foo(unsigned);
}

On the system I checked with, int=4, long=long long=8, and GCC reports:
#define __SIZE_TYPE__ long unsigned int
It only matched size_t to unsigned long, failing a check for both unsigned and 
unsigned long long.

[file using foo(unsigned long):]
$ cc -c typeof_size_t.c
[Change the file to foo(unsigned):]
$ cc -c typeof_size_t.c
typeof_size_t.c: In function ‘typeof_size_t’:
typeof_size_t.c:13: error: void value not ignored as it ought to be

I do not have the time in the short term to do this, but perhaps could in a 
month or so.  However, there are probably others more familiar with configure 
than I am that would be better suited, anyway.
Of course, this would only help when GCC is used, and would still leave the 
question of how to handle non-GCC compilers.

Craig
>