Re: stdin seekable failure

[Bruno Haible]

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