From:	"Adam" <bikko AT ix DOT netcom DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	C++ fstream class problems. bugs?
Date:	30 Nov 1996 12:20:57 GMT
Organization:	Netcom
Lines:	77
Message-ID:	<01bbdeca$2344eba0$7568d9ce@#bikko>
NNTP-Posting-Host:	als-il4-53.ix.netcom.com
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Hello.  I'm writing a program that uses the standard C++ fstream class and
the seekg() member function seems to be misbehaving.

Note:  I'm using binary mode.
If I call seekg(0, ios::end), and then call tellg(), it returns 0.
Shouldn't the arguments (0, ios::end) put the read/write "pointer" at the
end of the file?  I haven't been able to determine the size of a file
because of this, and, when writing a bunch of data and then calling
seekg(0), then I can't read any data without getting an EOF error.  In case
you're wondering/it matters, I'm using my own file class which checks for
errors anytime one may happen, but I do not believe it is causing the
problems.

Here's a small program that shows the problems.

#include <iostream.h>
#include <fstream.h>

int main(void)
{
    unsigned long ulCount;
    unsigned long ulValue = 1;
    fstream fTest;

    fTest.open("test.bin", ios::binary | ios::out);

    // write ten ulongs for test
    for (ulCount = 0; ulCount < 10; ulCount++)
    {
        fTest.write(&ulValue, 1 * sizeof(unsigned long));
        if (!fTest)
        {
            cerr << "Error writing to file TEST.BIN" << endl;
            return (1);
        }
    }

    // rewind file
    fTest.seekg(0);

    if (!fTest)
    {
        cerr << "Error seeking to position 0" << endl;
        return (1);
    }

    // file is at beginning, so this should not make an error!
    fTest.read(&ulValue, 1);

    if (!fTest)
    {
        cerr << "Error reading ulong" << endl;

        if (fTest.eof())
           cerr << "(EOF)" << endl;

        return (1);
    }

    fTest.close();

    return (0);
}

This program says, "
Error reading ulong
(EOF)" when I run it.

The somewhat extensive error checking is to simulate my DiskFile class'
error checking, and so you know when the problem happens.  I have a feeling
this is either a stupid mistake on my part :) or a library bug.

Any help about this would be appreciated, please e-mail me (and post if you
like).

Bikko
bikko AT ix DOT netcom DOT com

- Raw text -