Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: vfscanf in newlib
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Date: Tue, 24 Apr 2001 12:53:10 +1000
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08EF27@itdomain002.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: vfscanf in newlib
Thread-Index: AcDMaNsTRQLog5DSRdS8xO5ByqFWEgAAEtwQ
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>,
        <cygwin-developers AT cygwin DOT com>, <jjohnstn AT cygnus DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id XAA03347

> -----Original Message-----
> From: Charles S. Wilson [mailto:cwilson AT ece DOT gatech DOT edu]
> Sent: Tuesday, April 24, 2001 12:52 PM
> To: cygwin-developers AT cygwin DOT com; jjohnstn AT cygnus DOT 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
threadsafe. 

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
>