------- Additional Comments From pcarlini at suse dot de 2005-04-29 17:28
-------
Indeed, this is easily explained considering that we have a new optimization
that issues larger underlying read sys-calls (have a look to xsgetn in
fstream.tcc
to see what I mean): when everything goes well ;) are you noticing measurable
performance improvements? When pipes are involved, I'm not sure we can call this
a bug, because, when 27.6.1.3/28 talks about "end-of-file occurs on the input
sequence" it refers, in this case, not to the underlying file that you are
piping
but to the pipe itself and, at that moment, indeed the pipe cannot make
available
all the characters requested. I'd like to know your opinion, as a user: are you
noticing worthwhile performance improvements? Would you consider very annoying
trying to read again (calling clear()), when pipes are used? In case, disabling
the optimization to be safe would be very easy.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286
