Bug 97293 - Subsequent ifstream open fails for short files with no end-of-line (EOL)
Summary: Subsequent ifstream open fails for short files with no end-of-line (EOL)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc3   
(Show other bugs)
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-06-12 18:31 UTC by Arthur Person
Modified: 2007-04-18 16:54 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-17 16:04:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Arthur Person 2003-06-12 18:31:16 UTC
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
--infodir=/usr/share/info --
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)

#include <iostream>
#include <fstream>
#include <iomanip>
#include <string>
#include <math.h>
#include <stdlib.h>
#include <cstdio>
#include <sys/stat.h>
#include <unistd.h>

using namespace std;

int main (void)

int i;
ofstream ou2;
ifstream in2;
char s[200];
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.
  for(i=0;i<5;i++) {
     //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;
     if (!in2){
       cout << "Cannot open input file" << endl;
     else {
       in2 >> s;
     cout << "String read is: " << s << endl;


Version-Release number of selected component (if applicable):

How reproducible:

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

Additional info:

Comment 1 Arthur Person 2003-06-17 15:13:35 UTC
I've discovered that adding in2.clear() immediately before in2.open apparently
clears error bits and allows the code to work.

Comment 2 Jakub Jelinek 2003-06-17 16:04:42 UTC
That's what you should do.
This behaviour is mandated by ISO C++98.

Comment 3 Arthur Person 2003-06-17 18:58:07 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.