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

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <Pine.SOL.3.91.1010702115557.3441E-100000@taarna.cygnus.com>,
Benjamin Kosnik <bkoz@redhat.com> writes:

>> >> + #if _GLIBCPP_AVOID_FSEEK
>> >> +     __in_bufsize = 1;
>> >> + #endif
>> >> + 

> Perhaps I'm missing something, but if this works with and without fseek, 
> then why have this bit at all?

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.

Here is the comment I propose to add here to clarify this oddity:

#if _GLIBCPP_AVOID_FSEEK
    // Platforms that prefer to avoid fseek() calls on streams only
    // get their desire when the C++-layer input buffer size is 1.
    // This hack hurts performance but keeps correctness across
    // all types of streams that might be attached to (e.g.) cin.
    __in_bufsize = 1;
#endif

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.

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

Regards,
Loren