vfscanf in newlib

Charles S. Wilson cwilson@ece.gatech.edu
Sat Apr 21 10:37:00 GMT 2001


> Subject: Re: vfscanf in newlib
> Date: Sat, 21 Apr 2001 11:05:08 +0200
> From: Corinna Vinschen <vinschen@redhat.com>
> Reply-To: Corinna Vinschen <cygwin-developers@cygwin.com>
> To: cygwin-developers@cygwin.com
> 
> On Sat, Apr 21, 2001 at 01:21:30AM -0400, Charles Wilson wrote:
> > I've just discovered that I get a coredump with all three when I try to
> > run ssh.  #$!@&$
> 
> I just build the latest from CVS and it's running fine, even ssh and
> sshd.
> 
> Corinna

Thank you.  I guess that means the answer from my email is #3: I've
somehow lost the ability to build a working cygwin snapshot from a
perfectly good codebase.  Funny, I don't remember the surgeon saying
"Ooops" during my recent brain surgery.... :-)

--Chuck


> Subject: Re: vfscanf in newlib
> Date: Sun, 22 Apr 2001 00:05:36 +1000
> From: "Robert Collins" <robert.collins@itdomain.com.au>
> To: "Charles Wilson" <cwilson@ece.gatech.edu>
> CC: <cygwin-developers@cygwin.com>,
>      <jjohnstn@cygnus.com>
> 
> ----- Original Message -----
> From: "Charles Wilson" <cwilson@ece.gatech.edu>
> To: "Robert Collins" <robert.collins@itdomain.com.au>
> Cc: <cygwin-developers@cygwin.com>; <jjohnstn@cygnus.com>
> Sent: Saturday, April 21, 2001 3:21 PM
> Subject: Re: vfscanf in newlib
> 
> > Robert Collins wrote:
> > >
> > > A __cursory__ conde read through gives me the impression that
> > > simultaneous calls with the same file may result in undefined results.
> > >
> > > buffer wise it should be ok, but don't use the same handle twice. I
> > > don't know that the SUS has to say about the _r function w.r.t. the file
> > > in use, but I would expect that two calls from two threads to one of the
> > > _r functions should result in one blocking until the other finishes
> > > scnaning, not them interleaving fread calls.
> > >
> > > I may be completely off-base here though.
> >
> > Maybe.  I just discovered something -- which *MAY* be related to my
> > changes, or *MAY& be related to other changes.  I've built three
> > cygwin1.dll's in the last two days.
> 
> I'm looking at the original function that you are wrapping: I don't
> think your changes will make it worse, just that the _r functions may be
> reentrant, but not threadsafe. That may be an issue with increasing
> threaded applications on cygwin...
> 
> I don't think this should stop the code going in, just that someone
> should go through that code carefully.

Didn't somebody already do a threadsafeness audit of newlib?  If so,
then we don't want to break threadsafeness with these changes.  I'm not
familiar with threaded code in C; what is neccessary to insure that a
given function is both reentrant and threadsafe (if a block of code is
threadsafe it is automatically reentrant, but a reentrant block is not
necessarily threadsafe, right?)

--Cbuck



More information about the Newlib mailing list