From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
Single line files with no end-of-line fail to open on 3rd and successive tries
but work fine when and end-of-line (line feed) is included. The following
program demonstrates the problem (uncomment the appropriate in2.open line):
// Test program to demonstrate nature of open file failure
// when no eol is present in an input file. 06/12/03.
/* gcc -v shows:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
enable-shared --enable-threads=posix --disable-checking --with-system-zlib
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
using namespace std;
int main (void)
struct stat statbuf;
ou2 << "-99" << endl;
ou2 << "-99";
// First two opens work, last 3 fail when no end-of-line is present
// in input file. gcc V 3.2.2. June 12, 2003, RH9.
//File with 3 characters + end-of-line
//File with 3 characters and no end-of-line
cout << "in2: " << in2 << endl;
cout << "in2.bad: " << in2.bad() << endl;
cout << "in2.good: " << in2.good() << endl;
cout << "Cannot open input file" << endl;
in2 >> s;
cout << "String read is: " << s << endl;
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Run included code
Actual Results: The error was produced.
Expected Results: Code should have returned the data when the end-of-file was
I've discovered that adding in2.clear() immediately before in2.open apparently
clears error bits and allows the code to work.
That's what you should do.
This behaviour is mandated by ISO C++98.
Okay, I see what's happening now. Clearing status before open is a wierd
requirement. I would have expected that when a file is closed that status would
be reset to default values. I haven't seen any examples that use clear() before
open(), but I'm not real experienced at c++ either. Thanks for pointing this out.