This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC 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: libstdc++/9533: Regression: Can't read from tty with ifstream


The following reply was made to PR libstdc++/9533; it has been noted by GNATS.

From: Paolo Carlini <pcarlini at unitus dot it>
To: =?ISO-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02 at ru dot is>
Cc: paolo at gcc dot gnu dot org,  gcc-bugs at gcc dot gnu dot org,  nobody at gcc dot gnu dot org, 
 gcc-gnats at gcc dot gnu dot org,  libstdc++ at gcc dot gnu dot org
Subject: Re: libstdc++/9533: Regression: Can't read from tty with ifstream
Date: Mon, 03 Mar 2003 14:16:37 +0100

 P=E9tur Run=F3lfsson wrote:
 
 >>    Patching: indeed, reverting this hunk of 6746 commit:
 >>   =20
 >>    +
 >>    +	    // Set input to nonblocking for fifos.
 >>    +	    if (__mode & ios_base::in)
 >>    +	      fcntl(this->fd(), F_SETFL, O_NONBLOCK);
 >>    +
 >>   =20
 >>    Fixes the problem without regressing on 6746.
 >>   =20
 >>
 >Interesting. I would have thought that removing this would
 >cause the call to underflow() in basic_filebuf::open() to
 >block, causing the test case to wait for input *before*
 >printing out the prompt (this seems to be the reason that
 >non-blocking input is specified).
 >
 Yes, you are right. My bad.
 I didn't notice that since was using a further reduced :( testcase.
 Also, we got a regression elsewhere by simply reverting that hunk (not=20
 on 6746): see
 the libstdc++ list.
 
 >So far, this is what I think is going on:
 >* non-blocking input is specified so underflow() doesn't
 >  block (which is wrong, underflow() should block).
 >* underflow() must not block because it is called from
 >  open() which must not block.
 >* open() calls underflow() so that in_avail() will return
 >  non-zero after open() (libstdc++/6746).
 >
 Agreed.
 
 >However, I don't see how calling underflow() from open()
 >fixes libstdc++/6746.
 >
 I concur, but in fact it does.
 
 > Unless I am missing something,
 >readsome will return up to BUFSIZ characters, and then
 >return 0 until the end of time.
 > =20
 >
 Paolo.
 


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