This is the mail archive of the
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"
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
This isn't especially helpful, sorry about that.