Re: tellg modifying the state of an input file stream

[Brian Dessent <brian at dessent dot net>]

(CC and reply-to set to mingw list)

Ivan Kolev wrote:

> OK, then what's the part of MinGW between libstdc++ and MSVCRT.DLL ? If libstdc++ calls ftell/fseek directly from MS's runtime library, how's MinGW related here?

"mingw" is not a very precise word.  It is just the name of a project
that distributes a toolchain.  The "minimal" in its name reflects that
its goal is to provide the ability to produce binaries that are
standalone and don't require any compatibility layers or additional
runtime support libraries.  As such, aside from libmingwex (a static
library that suppliments MSVCRT with some missing C99 support), there is
very little library code; what you get is just direct access to what the
system provides.  So, there is no part between libstdc++ and MSVCRT.

But the issue at hand is "mingw related" because here "mingw" is being
used as a term to describe an environment / platform / paradigm, that of
using the gcc+binutils toolchain to build MSVCRT-based programs.

> That testcase looks a bit complex, though if the result is real it definitely means a bug in MSVCRT (I may try to reproduce it if I find the time).

The braindead html entity mangling of sourgeforge does not aid in its
inspection either.

> * Seeking with an offset of 0 relative to any of the origin values.
> ( my remark - including fseek(f,0,SEEK_CUR) which is expectedly used by tellg() )
> * Seeking from the beginning of the file with an offset value returned from a call to ftell."
> If any of these guarantees were broken, it would mean a *bug* in MSVCRT, not a "feature", even MS wouldn't deny that. And if client code adheres to these requirements, it should have no problems.

I don't know the details here of what exactly is or isn't supported, but
I do trust Earnie Boyd's conclusions, as I am very sure that he has
looked into this in great detail in the past.

> I had in mind Dinkumware's C++ library implementation (coming free with VC2005), which also uses MSVCRT's fseek/ftell underneath and works fine (I haven't tried STLPort).
> So, is this picture right?
> 
> Dinkumware  libstdc++
>       \    /
>       MSVCRT

Well there are more complications here.  There are multiple versions of
the Microsoft C library: MSVCRT, MSVCR70, MSVCR71, MSVCR80.  They
roughly correspond to the versions of the Visual Studio product, so you
may actually be comparing a very old version with a much newer version
that has bugs fixed.  Mingw (or rather the w32api package) includes
import libraries for these newer versions, and they can be used instead,
but therein lies another problem.

The old MSVCRT is the only one that has been deemed by MS a "system
component" and guaranteed to exist on any windows system.  If you target
one of the newer versions of the library you have to arrange to
distribute this newer version along with your binary, and conditionally
install it in your installer only if it doesn't already exist on the
user's system.  And this means shipping Microsoft redistributable code
with your product, which of course is permitted to licensees of the
Visual Studio product, but I certainly don't know the implications of
this for someone using only a mingw toolchain.  So for this reason and
for the reason of wanting to avoid needing to distribute extra things
with generated binaries, the mingw gcc specs file contains only
"-lmsvcrt", so even if a newer version is present it won't be used.

I don't know if any of this is actually relevant; it's just another
thing to consider when you are comparing mingw/gcc to Visual Studio.

> First, where's MinGW on that picture? Second, if the picture's right and my simple test case works correctly with MSVCRT (in the FILE* case, both with MinGW/GCC 3.4.5 and VC2005) and Dinkumware (in the streams case on VC2005), then doesn't this lead again to libstdc++ ?

I don't know why your test case works fine with plain C FILE streams but
fails with STL.  But as I said earlier I suspect it might be luck,
perhaps because you're only dealing with a file that contains a few
characters and would fit entirely into a default buffer.  Try with a
more significant input file, and try the other testcase.

Brian