From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12352 invoked by alias); 3 Mar 2003 13:26:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 12337 invoked by uid 71); 3 Mar 2003 13:26:00 -0000 Date: Mon, 03 Mar 2003 13:26:00 -0000 Message-ID: <20030303132600.12336.qmail@sources.redhat.com> To: paolo@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Paolo Carlini Subject: Re: libstdc++/9533: Regression: Can't read from tty with ifstream Reply-To: Paolo Carlini X-SW-Source: 2003-03/txt/msg00078.txt.bz2 List-Id: The following reply was made to PR libstdc++/9533; it has been noted by GNATS. From: Paolo Carlini To: =?ISO-8859-1?Q?P=E9tur_Run=F3lfsson?= Cc: paolo@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.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.