[RFC] PR5820: two CTRL-D are not enough?!?

Loren James Rittle rittle@latour.rsch.comm.mot.com
Tue Apr 2 00:58:00 GMT 2002

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

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.


More information about the Libstdc++ mailing list