This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH 64bit] ssize_t
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