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 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
>ssize_t.

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.

That's certainly a lot cleaner and less error-prone than littering code
with

#if defined(SOME_ARCHITECTURE) || defined(SOME_OTHER_ARCHITECTURE)
typedef unsigned long ssize_t
...

vs.

#if __WORDSIZE == 64
typedef unsigned long ssize_t

cgf


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