This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Strange stream behaviour
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.