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: Sat, 1 Feb 2003 13:30:03 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: 1.3.20
Message-ID: <20030201183003.GB3005@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20030201041117 DOT GA20843 AT redhat DOT com> <3 DOT 0 DOT 5 DOT 32 DOT 20030201061709 DOT 0080be50 AT h00207811519c DOT ne DOT client2 DOT attbi DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3.0.5.32.20030201061709.0080be50@h00207811519c.ne.client2.attbi.com>
User-Agent: Mutt/1.5.1i

On Sat, Feb 01, 2003 at 06:17:09AM -0500, Pierre A. Humblet wrote:
>At 11:11 PM 1/31/2003 -0500, you wrote:
>>Given my botch in passwd.cc, we should probably release a new version
>>of cygwin ASAP.
>
>Chris,
>
>I had a look at passwd/group. 
>
>linebuf must be static but not NO_COPY, as a forked process will inherit
>malloced objects from its parent and the passwd_buf object may point to
>linebuf.
>
>The internal cygwin functions should only read the pwd/grp if they have 
>never been read, but not reread then after a change (I explained why 
>before).

Translation: "cgf - when you did your automatic conversion of the old
code to the new, structured code, you got the logic backwards."

I think I'll just get rid of the default entirely.  Nearly every time I
use a default arg, I end up regretting it, just like this time.

>Next, I would call pr.refresh (true) from setpwent() but I would not call
>pr.refresh from getpwent (rereading the passwd file while scanning can lead
>to strange results). Ditto for setgreent and getgreent32

Ok.  Don't you still have to call pr.refresh in the get??ent case in
case it isn't initialized?  Is it guaranteed to be initialized by the time it
gets to the get* functions?  Otherwise, I agree with your assessment.

>There is no reason to call pr.refresh in getpass(), that is only an input 
>function to read a password, nothing to do with the /etc/passwd file.

Yep.

>If internal functions never reread the file ("check" is false), you can 
>revert the pglock->acquire test you added yesterday. It will never be 
>reached while loading the file and will never be true in other circumstances.

I don't know.  That is a very cheap test.  It's just a couple of assembly
instructions.  I'm inclined to leave it in just for paranoia's sake.

>>Besides Pierre's outstanding ntsec problems, are there other issues that
>>would hold up a release?
>
>My only change that is urgent is the chown fix. I have tested all variations
>I could think off and could send you a patch w.r.t the current cvs (I haven't 
>heard from Corinna recently).

Thanks,
cgf