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 11:10:00 -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: <20030122161000.GF4903@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> <20030122154704 DOT GE4903 AT redhat DOT com> <20030122155757 DOT GA16081 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030122155757.GA16081@cygbert.vinschen.de>
User-Agent: Mutt/1.5.1i

On Wed, Jan 22, 2003 at 04:57:57PM +0100, Corinna Vinschen wrote:
>On Wed, Jan 22, 2003 at 10:47:04AM -0500, Christopher Faylor wrote:
>> On Wed, Jan 22, 2003 at 11:29:19AM +0100, Corinna Vinschen wrote:
>> >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?
>
>We need 32 and 64 bit versions to support old and newly build apps,
>same as off_t.  Another problem is that off_t is used in the FILE
>struct :-P

[I know that we've discussed this but never here, so forgive me]

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?

Actually, it would be sort of cool to switch to a more modern version
of these functions.

Hmm.  We could make 1.5.x a "newlib free" version, too...

>> >					    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.  :-)
>
>Yeah, and I woke up this morning with pedantic mode switched on
>so I couldn't resist ;-)

LOL.

>> 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.*
>
>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"]

cgf