Eric Blake wrote: > However, the fflush module is still broken for mingw when reading files in > text > mode that have plain LF line endings. It appears that mingw's ftell tries to > compensate for \r\n line endings in text mode, but does the compensation even > when there is just a plain \n line ending, which means that ftell can report > the wrong offset (since the \r got stripped before the read buffer was > populated, there is no way to tell if the remaining \n in the read buffer > were > coupled with a stripped \r or not). I'm still trying to think of ways to > make > fflush reliable in spite of that limitation.
If you don't see a solution - and I don't see one - then maybe the fix is to treat streams opened in O_TEXT mode like non-seekable streams. msvcrt's ftell and ftelli64 functions do this infamous hack if (_osfile(fd) & FTEXT) != 0; I propose to modify fseek, fseeko, ftell, ftello, so that they fail in this case, making the stream look like non-seekable. This will prevent loss of data when reading text files with Unix line conventions. > Also, in testing this, I discoverd that cygwin stdin has a bug - when a > process > starts, stdin is always in 32-bit mode (even though cygwin has been compiling > in 64-bit mode since cygwin 1.5.0). But since cygwin ftello really invokes > ftello64 under the hood, and ftello64 fails unless the file is open in 64-bit > mode, it is possible for ftell(stdin) to return non-negative while ftello > (stdin) fails with EOF. Can't you then just write an rpl_ftello that tries ftello and then ftell? Or is this impossible because it kills the failure detection when 4 GB have been read from a 32-bit stream? Bruo
