[RFC/Patch] What about using seekoff(-1, ...) for unbuffered underflow?

[Paolo Carlini]

Benjamin Kosnik wrote:

>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.
>
Thanks.

>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....)
>
You will find attached my second try, along the lines suggested by Nathan
(but honestly I had already started working on it before Nathan's
interesting reply ;)

This means: no seeks (this answers also a concern raised privately by
Pétur as regards pipes), a simple sbumpc().

Seems like a possibility...

However, I agree _completely_ with your concerns (I hadn't considered
locales, damn!) and also, let me add that, even if we don't care much,
this additional use of the single pback char we have available implies
that (both in yours and mine solution) after any sgetc() the pback area
is full! Therefore no chars can be pback at all upon request!
This seems bad.

What to do?

1- Adding another hidden "pback" area only for unbuffered sgetc()-type
situations: this answers my last concern but definitely not yours involving
locales.
2- Resorting to seeks (as in my first proposal): indeed unbuffered sgetc()
would be slowed down but we have a _really_ simple and correct solution.
3- Something else... What????

Paolo.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_prop2
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20030606/cd1edb9b/attachment.ksh>