This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setregid() and setreuid() implementation proposal


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]