This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH for libstdc++/2211 (some discussion held on gcc-bugs)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]