Re: [RFC/Patch] What about using seekoff(-1, ...) for unbufferedunderflow?

[Benjamin Kosnik <bkoz at redhat dot com>]

If you can prove that using the pback buffer leads to incorrectness, or
a substantial slowdown for buffered sbumpc, than I will be more
favorably inclined in your proposed patch. After all,
__gnu_cxx::stdio_sync_filebuf is what should be used if a speedy
solution (and codecvt lacking interpretation) is desired.

Your aesthetic arguments about _M_buf_size and the purity of
non-virtuals I agree with, but don't find especially compelling. I
remain unconvinced that the performance issues can be measured.

I will help you prove me wrong though!

Here's an idea that may prove the unbuffered pback usage wrong:  you'd
need to do a getc on an unbuffered input stream, then change locales to
one that does the codecvt conversion differently, thus invalidating
(possibly?) the stored pback character. It's hard, but perhaps not
impossible, to prove this, and I'd certainly like to see the test case.
There are some similar proofs done in the testsuite with overflow. (This
is certainly easier than trying to use the pback buffer without
modifying sbumpc....)

best,
benjamin