Mail Archives: cygwin-developers/2002/05/29/12:04:54
Hi,
now I've changed to 32 bit uids the same way I changed to 32 bit gids.
Yet none of the new 32 bit functions are exposed to the public. The
only way to retrieve the correct 32 bit uids and gids currently is
using the changed `external_pinfo' struct which now contains additional
members "uid32" and "gid32". For an example see the patch to ps.cc.
At this point we are not *that* far away from switching over to 32 bit
ids and 64 bit file offsets. This will be done by a change to the Cygwin
Makefile so that newly build applications will get the 32 bit functions
automagically while appliocations build with older versions of Cygwin
will still use the old 16 bit functions (see the part in the Makefile
which maps the regex symbols to the new POSIX functions). The second
change needed is to define __CYGWIN_USE_BIG_TYPES__ in the preprocessor
stage. Otherwise a type mismatch for off_t, uid_t, gid_t and struct
group would occur at runtime.
AFAICS, there's still something missing to be able to switch eventually.
Newlib defines fpos_t as long which isn't sufficient for 64 bit file
access, obviously. SUSv3 defines fpos_t as a type "containing all
information needed to specify uniquely every position within a file."
So, we will have to change that as well. Unfortunately. This means,
we have to define our own functions fgetpos and fsetpos. Do I forgot
something? Well, another point is to look into newlib carefully to
find occurences of calls to the old 32 bit off_t and 16 bit uid/gid
functions. AFAIK, there are no uid/gid related function calls but
probably calls to lseek and such.
If anybody wants to take a stab on this, I'd be very glad. Just
reporting suspect functions in newlib would already be helpful.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -