Why does my program produce different results on Windows and Linux, about file reading with ifstream?

Question

I have a program shown as follows. For it I have several questions:

1). Why does it produce different results on different platforms? I'll paste the screen-shots later.

2). I'm using a fail() method to check if the "file.read()" failed. Is this correct? I use fail() method because this web page says this:

The function returns true if either the failbit or the badbit is set. At least one of these flags is set when some error other than reaching the End-Of-File occurs during an input operation.

But later I read this page about istream::read() here. It says the eofbit and failbit would always be set at the same time.. Does this mean that a normal EOF situation would also result in that fail() returns true? This seems to conflict with "other than reaching the End-Of-File occurs"..

Could anyone help me clarify how I am supposed to use these methods? Should I use bad() instead?

My program

#include <iostream>
#include <fstream>
using namespace std;

#ifdef WIN32
char * path="C:\\Workspace\\test_file.txt";
#else
char * path="/home/robin/Desktop/temp/test_file.txt";
#endif

int main(int argc, char * argv[])
{
    ifstream file;

    file.open(path);
    if (file.fail())
    {
        cout << "File open failed!" << endl;
        return -1;  // If the file open fails, quit!
    }

    // Calculate the total length of the file so I can allocate a buffer
    file.seekg(0, std::ios::end);
    size_t fileLen = file.tellg();
    cout << "File length: " << fileLen << endl;
    file.seekg(0, std::ios::beg);

    // Now allocate the buffer
    char * fileBuf = new (std::nothrow) char[fileLen+1];
    if (NULL == fileBuf)
        return -1;
    ::memset((void *)fileBuf, 0, fileLen+1);    // Zero the buffer

    // Read the file into the buffer
    file.read(fileBuf, fileLen);
    cout << "eof: " << file.eof() << endl
         << "fail: " << file.fail() << endl
         << "bad: " << file.bad() << endl;
    if (file.fail())
    {
        cout << "File read failed!" << endl;
        delete [] fileBuf;
        return -1;
    }

    // Close the file
    file.close();

    // Release the buffer
    delete [] fileBuf;

    return 0;
}

The test_file.txt content(shown with "vim -b". It's a very simple file):

Result on Windows(Visual Studio 2008 SP1):

Result on Linux(gcc 4.1.2):

Answer 1

Does this mean that a normal EOF situation would also result in that fail() returns true? This seems to conflict with "other than reaching the End-Of-File occurs".

I recommend using a reference that isn't full of mistakes.

http://en.cppreference.com/w/cpp/io/basic_ios/fail says:

Returns true if an error has occurred on the associated stream. Specifically, returns true if badbit or failbit is set in rdstate().

And the C++ standard says:

Returns: true if failbit or badbit is set in rdstate().

There's no "other than end-of-file" thing. An operation that tries to read past the end of the file, will cause failbit to set as well. The eofbit only serves to distinguish that specific failure reason from others (and that is not as useful as one might think at first).

---

I'm using a fail() method to check if the "file.read()" failed. Is this correct?

You should simply test with conversion to bool.

if(file) { // file is not in an error state

It's synonymous with !fail(), but it's more usable, because you can use it to test directly the result of a read operation without extra parenthesis (things like !(stream >> x).fail() get awkward):

if(file.read(fileBuf, fileLen)) { // read succeeded

You will notice that all read operations on streams return the stream itself, which is what allows you to do this.

---

Why does it produce different results on different platforms?

The difference you're seeing between Windows and Linux is because the file is open in text mode: newline characters will be converted silently by the implementation. This means that the combination "\r\n" (used in Windows for newlines) will be converted to a single '\n' character in Windows, making the file have only 8 characters. Note how vim shows a ^M at the end of the first line: that's the '\r' part. In Linux a newline is just '\n'.

You should open the file in binary mode if you want to preserve the original as is:

file.open(path, std::ios_base::in | std::ios_base::binary);

Answer 2

I guess, the problem here with the different execution is the DOS(Window) vs. UNIX text file convention.

In DOS, a line ends with <CR><LF>, and this is read/written together as '\n'. Thus, in Windows your file is at the end, but in UNIX not, since there is one character left.