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:[EMAIL PROTECTED] Red Hat, Inc.
