http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
Andrew Ayer <bugs at mm dot beanwood.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugs at mm dot beanwood.com
--- Comment #4 from Andrew Ayer <bugs at mm dot beanwood.com> 2013-02-24
22:05:26 UTC ---
(In reply to comment #2)
> I want to understand how critical this additional underflow is,
> performance-wise
There are also correctness implications: what if you're trying to ignore
all the bytes you know are available to be read without blocking? Then
the extra underflow blocks, possibly forever if the program is prevented
from taking action that would result in the underflow completing.
I got bitten by this because I was trying to ignore data from a socket.
Note that the standard has similar language for read(char_type*,
streamsize) ("either of the following conditions") but the library in
effect checks for n characters being reached before checking for eof:
if you read() exactly the number of characters left in the stream,
eofbit is not set. So the library isn't currently consistent across
all the various istream functions.
I would argue that the current behavior of ignore() is actually contrary
to the standard. If the standard says "until any" then ignore()
needs to terminate when n characters have been extracted. But if it
first checks for eof and blocks forever, then it doesn't terminate.
Perhaps this is why getline explicitly mentions the order: in that case
the standard really does want eof to be checked first.
