Re: [Mingw-users] std::fstream bug?

[Greg C. <chi...@mi...>]

Al Stevens wrote:
> 
> > > Something is getting the internal file buffer out of whack. If the
> program
> > > does not do the tfile.get calls, the file is saved correctly. If you
> open
> > > the file with std::ios::binary, the problem does not happen, but, of
> course,
> > > the /n is not converted to /r/n.
> > >
> >
> > Give thanks to Mr. Bill.  It stems from the way the read function
> > returns 1 less than actually read after removing the \r.  The count of
> > bytes from read is == strlen of the data returned which is one less than
> > the the bytes on disk.  It's advised not to seek and tell in text mode.
> >   If you must have \r for good old Notepad but operate in binary mode
> > for seek and tell then write the \r yourself; that's what good old
> > Notepad does.
> 
> I don't quite buy that. The program has already written to the file. If you
> stopped there the problem would not occur. After that, the program *only*
> does a seekg to zero and reads the file. The text/binary nonsense might
> confuse it about the input, but the output should be complete by then. I

Let's try it with this modified version of your testcase.
All I did was add a '/*' and a '*/' to prevent read()
from being called. I even left the seekg() call intact.

#include <iostream>
#include <fstream>
static char tdata[100];
int main()
{
    // open fstream object for both input and output.
    std::fstream tfile("test.dat", std::ios::in | std::ios::out);
    if (tfile)   {
        tfile.seekp(0, std::ios::end);
        tfile << "\nMore test data";
        tfile.seekg(0);
/*
        int i = 0;
        while (!tfile.eof() && i < sizeof tdata)
            tfile.get(tdata[i++]);
        std::cout << tdata;
*/
    }
    return 0;
}

Administrator@ILUVATAR /c/tmp
$ cat test.dat
Test data
More test data

> believe that the t/b issue is at the root of the problem, but, this program
> only seeks to zero and ios::end. Both of which work while the program's
> running. Take another look at the program and at the text. There really is a
> bug in there somewhere. The iostream stuff is getting its seekg and seekp
> pointers confused.
> 
> And BTW, you can't blame the text/binary crlf stuff on Bill. Those modes
> date back to the old PDP-11 days and, later, CP/M, well before Bill had
> kicked Clearasil.

Was Earnie objecting to the text/binary dichotomy
as distasteful per se, or asserting that the msvc
rtl implements read() incorrectly for text mode?