Re: Strange stream behaviour

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

> It seems that the problem can be fixed by defining
> _GLIBCPP_AVOID_FSEEK for cygwin (at least my example works fine after
> rebuilding libstdc++ with this macro defined); without it text mode
> streams work incorrectly since in cygwin (and IMHO in most other
> systems with nontrivial end-of-line conversions for text files)
> seeking is guaranteed to work properly only for binary streams (it is
> said explicitly in cygwin docs; MSDN has such statement for
> Microsoft's runtime, so I guess Mingw port has similar problems).

_GLIBCPP_AVOID_FSEEK is described in libstdc++-v3/porting.texi as
being required when fseek can't be used on interactive streams.  It
looks like you may have found another use for that code path.

Would you provide the patch for your system's os_defines.h file?

> I'm not sure whether this is enough to make high-level input work
> correctly - it seems that seek is avoided only while reading one
> character at a time; IMHO it must be avoided in all operations based
> on sequental reading.

Yes, the ISO standard only guarantees one character of space for
ungetc().  The workaround provided by the _GLIBCPP_AVOID_FSEEK code
path must not make assumptions beyond that guarantee.  You will note
that input buffer size selection in libstdc++-v3/src/ios.cc is also
keyed off that macro.

Regards,
Loren