Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Wed, 22 Jan 2003 10:47:04 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: setregid() and setreuid() implementation proposal
Message-ID: <20030122154704.GE4903@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20030117120131 DOT GF1142 AT cygbert DOT vinschen DOT de> <20030116190119 DOT GD820 AT tishler DOT net> <20030117120131 DOT GF1142 AT cygbert DOT vinschen DOT de> <3 DOT 0 DOT 5 DOT 32 DOT 20030121202701 DOT 007db4f0 AT mail DOT attbi DOT com> <20030122014007 DOT GA23365 AT redhat DOT com> <20030122102919 DOT GA29236 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030122102919.GA29236@cygbert.vinschen.de>
User-Agent: Mutt/1.5.1i

On Wed, Jan 22, 2003 at 11:29:19AM +0100, Corinna Vinschen wrote:
>On Tue, Jan 21, 2003 at 08:40:07PM -0500, Christopher Faylor wrote:
>> On Tue, Jan 21, 2003 at 08:27:01PM -0500, Pierre A. Humblet wrote:
>> >Wouldn't this (post 1.3.19) instead be the right time to kick in the 
>> >uid32 code? Corinna had indicated in the fall that it was "just" (my
>> >words) a matter of introducing a few macros to split that change from 
>> >the offset64 stuff?
>
>Hmm, I was trying to avoid that but I'm not getting to change newlib
>for the necessary fpos_t changes.  And, honestly, I hate digging in
>newlib. 

I forget what the problem is here.  Couldn't we just define fpos_t to
be 64 bits?

>But it's not *that* simple:
>
>- sec_acl.cc is still using __aclent16_t instead of __aclent32_t.
>
>- Create a new define, say __CYGWIN_USE_32BIT_IDS__
>
>- Set this define in some Cygwin header (cygwin/types.h?) or
>  in gcc's specs file.
>
>- Change Cygwin's Makefile so that new applications are linked
>  against the new functions (same way as for regcomp/posix_regcomp
>  et al)
>
>And don't forget that all applications still use 16 bit ids as long
>as they aren't rebuild!

Right.  So, we go with the define in header, export in cygwin.din
method for dealing with that.

>> Sure.  I plan on introducing the device file and fifo support too.
>> Maybe it's a good time to kick the DLL to 1.4.0 since this will be
>                                            ^^^^^
>					    1.5.0

Yes, as I was drifting off to sleep last night, I realized that I'd
awake to just this correction from you.  :-)

>> a DLL with major new features.  Assuming all goes well, there will be
>> mount table changes coming soon, too.
>
>Would that imply a chance to correct a mistake in the API?  Once I
>introduced a function lacl() which is completely useless and has
>never been defined in Solaris nor in POSIX.  May I just trash it then?

As long as no one is actually using lacl, I don't see any reason not
to trash it.  Otherwise, keeping an obsolete function around which does
nothing doesn't seem to be too much of a burden.

Maybe the best plan would be to keep the 1.3.* branch around and start
making drastic changes to 1.5.*.  The first checkin could be device
handling, since that is nearly ready.  Then we could add 32/64 bit
support.  Eventually, around 1.5.8 or so, we could make 1.5 the latest
release and trask 1.3.*

cgf