This is the mail archive of the newlib@sources.redhat.com 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] |
Hi, we're currently in Cygwin trying to get rid of some restrictions given by too small datatypes. You did perhaps already see that some datatypes aren't defined anymore in newlib if compiling under Cygwin. This is due to the fact that we moved most of that stuff into special Cygwin files (e. g. cygwin/types.h, cygwin/stat.h). The way we are going is trying to be backward compatible. Old applications using 32 bit file access should still work under a 64 bit Cygwin. Therefore we are changing Cygwin internally to 64 bit but we keep the entry points for the old applications to jump into e. g. lseek() while there's also a function lseek64() which is used if a newly compiled application is calling lseek(). There's obviously also the time "in between", where we are changing headers and Cygwin itself, while applications still link against the 32 bit types and functions. Therefore the types exist in two variations, e. g. __off32_t and __off64_t. By using the define __CYGWIN_USE_BIG_TYPES__ the application is getting the old 32 or the new 64 bit types. Well, two problems are still left. - newlib is internally using `off_t'. This doesn't fit well in our concept, obviously. To build correctly, the functions using off_t would either have to be changed to use __off64_t if they are only used internally or to use __off32_t if the off_t is used as parameter to an exported function. Apparently this doesn't work with any other target since these datatypes aren't defined there. - The crux is the datatype fpos_t. This datatype is supposed to be the same size as off_t. So it has to switched over to 64 bit the same way as off_t. Unfortunately fpos_t is used for a member of __sFILE, too. This makes life really hard. Ignoring the problems with the naming convention, using a __fpos32_t would keep the FILE functions from being able to seek correclty in big files, using __fpos64_t would change the size of FILE and so we have another datatype which has to exist in a 32 and a 64 bit version: FILE. This in turn requires to have two versions of nearly *every* FILE function. If we can't keep most of the functionality in newlib, we would have to implement all that functionality a second time in the Cygwin source *shudder*. We'd like to avoid that if possible. Sure, we need to implement some of these functions anyway, e. g. fseeko, but we don't want to have our own fopen, fseek, ftell, etc., etc. So, the question is, has anybody an idea how to get this done with as few headaches as possible? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |