This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/9533: Regression: Can't read from tty with ifstream
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: paolo at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 3 Mar 2003 13:26:00 -0000
- Subject: Re: libstdc++/9533: Regression: Can't read from tty with ifstream
- Reply-to: Paolo Carlini <pcarlini at unitus dot it>
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.