This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH 64bit] ssize_t
On Feb 20 12:19, Christopher Faylor wrote:
> On Wed, Feb 20, 2013 at 05:15:09PM +0100, Corinna Vinschen wrote:
> >On Feb 20 11:00, Christopher Faylor wrote:
> >> On Wed, Feb 20, 2013 at 04:42:02PM +0100, Ralf Corsepius wrote:
> >> >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.
> >In theory you're right. The problem with __WORDSIZE is just that it's
> >an architecture specific thingy. So you have to start with defining the
> >__WORDSIZEes of all newlib-supported CPUs, and only then you can define
> Of course. Obviously Linux has to deal with the same problem. They
> use architecture-specific header files but for the *86 class systems
> there is only one header file which makes the decision based on
> whether it's X86_64 or not.
Sure. And Cygwin already has a bits/wordsize.h file so it's no problem
for us. But we don't have this file for any other supported architecture
in newlib. That means, before you can define ssize_t based on __WORDSIZE,
you have to define it for all supported architectures. Otherwise you
would break all targets we forgot (and I don't really know any target
besides i386, x86_64 and xstormy16) , or you end up with
<easy wordsize based definition>
<all the other stuff we're just discussing>
which doesn't look like a big win in the current situation.