Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Wed, 22 Jan 2003 11:29:19 +0100 From: Corinna Vinschen To: cygwin-developers AT cygwin DOT com Subject: Re: setregid() and setreuid() implementation proposal Message-ID: <20030122102919.GA29236@cygbert.vinschen.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030122014007.GA23365@redhat.com> User-Agent: Mutt/1.4i 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. 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! > 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 > 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? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc.