Re: tellg modifying the state of an input file stream

[Brian Dessent <brian at dessent dot net>]

Ivan Kolev wrote:

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

> but I didn't quite understand the explanation... it was blamed on MS for some reason. Something like their fgetc or other part of the C library implementation doing something wrong with line endings. However, as I tested above, it seems fgetc/ftell is working fine in MinGW.

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.

> I'll post this on MinGW's list again to ask for an explanation. Because Earnie Boyd's statement (in the second link) that "You can't seek and tell on a text mode file, it's not a bug, it's a defined feature" doesn't seem right to me.

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
really relevant now, as there is no way to change it.  You can either
not use MSVCRT or you can open files in binary mode and make your code
recognise both types of line endings explicitly.

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

Brian