[RFD] Trying to move Cygwin over to 64 bit file access

[Corinna Vinschen]

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