This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PATCH for libstdc++/2211 (some discussion held on gcc-bugs)
- To: rittle at labs dot mot dot com
- Subject: Re: PATCH for libstdc++/2211 (some discussion held on gcc-bugs)
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Mon, 2 Jul 2001 12:44:38 -0700 (PDT)
- cc: libstdc++ at gcc dot gnu dot org
> Ah, I have bootstrapped and checked both ways with zero formal test
> suite regressions (i.e. both code paths "work") but recall that, at
> least, Solaris2 and BSD do not like it when fseek is called on
> interactive streams and/or pipes (typical cases for cin). No one has
> stepped forward with a proper dejagnu test that may flag the problem
> worked around by defining _GLIBCPP_AVOID_FSEEK. If that test was in
> the formal regression suite, then on my platform, then only the path
> that forces the input buffer size to 1 would pass the test.
Ok. Your comments look fine: please check in.
> Or, Benjamin, do you have an informed opinion on whether
> basic_filebuf<>::underflow() must reposition the stream pointer with
> seekoff() calls when C++ IO is unsynchronized with C IO (as it is
> currently seen to do)? It seems to me that this tedium must only be
> done in the synchronized IO case and even then only really works when
> the buffer size was exactly 1 anyway since, unless I have overlooked
> something obvious, other places that consume buffered input do not
> appear to explicitly resynchronize the position with a seekoff() call.
It's not just synchronizing with "C" I/O, it's synchronizing with the "C"
file position.
This is necessary for input | output files.
> If the calls to seekoff() in basic_filebuf<>::underflow() were only
> required when we are attempting to synchronize C++ IO to C IO, then
> the above hack could be removed as long as underflow was reworked
> to not call seekoff() whenever the stream was unsynchronized.
I'm not quite sure this is possible. I hesitate to say impossible though,
since I'm continually surprised with this stuff.
> I have attempted to explain this to the list before, but I have
> assumed that I am getting no response since I have not communicated
> the issue well enough yet...
Well, to be quite honest, I'm trying to finish up locales and thus am
putting IO into a lower priorty seems things seem to be mostly working.
Some of the filebuf bits will need to be reworked when locales are fully
implemented anyway.
This isn't especially helpful, sorry about that.
-benjamin