vfscanf in newlib

Robert Collins robert.collins@itdomain.com.au
Mon Apr 23 20:00:00 GMT 2001

> -----Original Message-----
> From: Charles S. Wilson [ mailto:cwilson@ece.gatech.edu ]
> Sent: Tuesday, April 24, 2001 12:52 PM
> To: cygwin-developers@cygwin.com; jjohnstn@cygnus.com
> Subject: Re: vfscanf in newlib
> Did the following patch get applied to CVS ?  If not, why 
> not? (I don't
> think Robert Collins' message (partially quoted below) was intended as
> an argument against it, especially given his second message (also
> quoted))  It's also not clear whether Robert was commenting on my
> *original* changes which Jeff later modified and accepted, or 
> the newer
> changes against Jeff's update.

I was commenting on the code in newlib prior to any changes. 

My third comment (later still) was that we should not implement any _r
(or otherwise specified as threadsafe) API functions unless they are

So IMO the non _r functions should go in; the _r ones shouldn't. (or if
they go in, don't export until the thread issue is looked into by
someone who knows that part of newlib more than I do :] ).
> 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.
> Robert Collins later wrote:
> > 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.
> --Chuck

More information about the Cygwin-developers mailing list