Re: tellg modifying the state of an input file stream

[Ivan Kolev <ikolev at abac dot com>]

> > Indeed, it seems the problem is more related to the C standard library (which as I understand is implemented by MinGW?), not the C++ library. Another reason 
> No, when you are using mingw you are using Microsoft's C library
> (MSCVRT.DLL) which is a closed source, proprietary black box.  There's
> no straightforward way for mingw to have any influence on the bugs or
> behavior of it, since it is a part of the operating system.

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?

> Yet, in your third link there is a testcase that uses only fgetc and
> ftell and exposes the defect, so it seems that you are just getting
> lucky in this particular case.

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 people that implemented MSVCRT decided to leave seeking on textmode
> files undefined, I guess because dealing with translating all the file
> offsets is not a simple task.  Whether it was a good idea or not isn't

Then the statement "You can't seek and tell on a text mode file" holds for MSVCRT? It doesn't seem possible to me... MSVCRT is old enough and this should have been reported and demanded to be fixed until now. From MSDN:

"For streams opened in text mode, fseek has limited use, because carriage returnâlinefeed translations can cause fseek to produce unexpected results. The only fseek operations guaranteed to work on streams opened in text mode are:
* 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.

> > And there are other C and C++ library implementations which don't have this problem on Windows.
>
> Of course, just because one particular implementation sucks doesn't mean
> they all have to.  Your testcase works fine under Cygwin (which
> implements its own entire C library, based on newlib.)

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

(sorry for the ASCII art needing a monospaced font, hope you get the idea)

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++ ?

Regards,
Ivan