setregid() and setreuid() implementation proposal

Corinna Vinschen
Wed Jan 22 17:33:00 GMT 2003

On Wed, Jan 22, 2003 at 11:10:00AM -0500, Christopher Faylor wrote:
> Couldn't we do a FILE64 trick?  Just create wrappers for all of the
> functions?  Or detect something about the FILE structure which would
> allow us to figure out which was being used?


> >May I dream?  Let's break binary compatibility with 1.3 and switch
> >over to 64 bit off_t/fpos_t etc and 32bit uid_t/gid_t once and for all.
> >No big chnanges to newlib needed then.  We could get rid of all
> >func32/func64 function pairs... sounds like holiday on Hawaii.
> That would imply a cygwin2.dll.  Do we really want to go there?  I could
> get rid of my signal-compatibility hacks, too.  And the termios hacks,
> and...
> [cgf takes quick gulp of coffee to "calm down"]

We shoudn't make haste... let's begin today with cygwin2.dll.

You surely remember your suggestion to switch over to cygwin2.dll with
cygwin1.dll being just a wrapper calling the functions in cygwin2.dll.
In cygwin1.dll we only keep function stubs, copying the datastructures
into the new form (32bit ids, 64 bit offsets) and calling the corresponding
functions in cygwin2.dll.

We could begin with cygwin2.dll w/o even to care for that backward
compatibility.  The first goal would be to have a stable cygwin2.dll
which can coexist with today's cygwin1.dll but without sharing any
datastructure (own process table etc).  If we have a stable cygwin2.dll,
we can begin to create the compatibility lib called cygwin1.dll.

We could get rid of so many kludges... see that I'm moved to tears? :-)


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

More information about the Cygwin-developers mailing list