Re: Strange stream behaviour

[Roman Belenov <rbelenov at yandex dot ru>]

Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

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

Actually the purpose is the same - to avoid fseek when its not
guaranteed to work correctly.

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

Since separate os_include_dir for cygwin didn't exist, I made one by
copying 'newlib' (used previously for cygwin), added
_GLIBCPP_AVOID_FSEEK to os_defines.h :

--- os_defines.h.old	Wed Oct 25 16:50:05 2000
+++ os_defines.h	Mon Oct  8 18:00:28 2001
@@ -35,6 +35,7 @@
 /* System-specific #define, typedefs, corrections, etc, go here.  This
    file will come before all others. */
 
+#define _GLIBCPP_AVOID_FSEEK 1
 
 #endif

and patched configure.target file:

--- configure.target.old	Sat Aug 18 23:23:13 2001
+++ configure.target	Mon Oct  8 18:06:17 2001
@@ -74,7 +74,7 @@
     os_include_dir="config/os/bsd/freebsd"
     ;;
   cygwin*)
-    os_include_dir="config/os/newlib"
+    os_include_dir="config/os/cygwin"
     ;;
   *djgpp*)
     os_include_dir="config/os/djgpp"


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

It seems that it was added after gcc-3.0.1 release - it is used only
in fstream.tcc there. Anyway, I'm not quite familiar with libstdc++-v3
internals; I guess people working on streams implementation will take
this behaviour into account and make required fixes someday (it seems
to me that buffering required for putback during sequental high-level
I/O, like reading numbers, should be done inside libstdc++).

BTW gcc-3.0.2 release is coming soon, are there any chances that this
_GLIBCPP_AVOID_FSEEK fix (or is it just a workaround ?) will be
included in it ?

-- 
 							With regards, Roman.