This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] PR5820: two CTRL-D are not enough?!?
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Tue, 2 Apr 2002 02:58:36 -0600 (CST)
- Subject: Re: [RFC] PR5820: two CTRL-D are not enough?!?
- References: <3CA6FE7D.7000200@unitus.it> <20020402071139.B45461@cantrip.org> <3CA96A7D.3030704@unitus.it>
- Reply-to: rittle at labs dot mot dot com
In article <3CA96A7D.3030704@unitus.it>,
Paolo Carlini <pcarlini@unitus.it> writes:
> A punctualization for Nathan and Loren: submitter maintains that 2
> CTRL-D should suffice if typed right after the number, on the same line,
> or a single CTRL-D alone at the beginning of the next line.
Sorry, before now, I didn't read the full PR. I now understand when 2
EOFs are required. If the terminal handler were not in a line mode;
then it should require only 1 EOF in all cases. Most (?) UNIX users
run their shell ttys in a line mode and thus the test case as
presented should require 2. In the nominal case I'm painting, only
one EOF is ever read by the program since the tty itself ate the first
one.
I agree with Nathan; this is a serious bug. I personally think it is
related to the seeking on an interactive stream.
> I have personally verified on i686-pc-linux-gnu that v3 needs 4 in the
> former case. Dunno about the latter.
Try recompiling your libstdc++ with _GLIBCPP_AVOID_FSEEK defined (drop
it in your os_defines.h file). I'd wager that your platform will
start to perform like mine... (i.e. correctly ;-)
Of course, there are performance tradeoffs (e.g. C++ input buffer size
is whacked to one when that macro is defined) which is why Linux
probably doesn't want to define it, if at all possible. OTOH, the
underlaying C input buffer size should still be/could be set to a
reasonable value thus somewhat negating the performance issue when
studied in a total system context.
Under the assumption that my guess is right, I hope this helps you
understand exactly what is breaking the test case.
Regards,
Loren