Bug 97293 - Subsequent ifstream open fails for short files with no end-of-line (EOL)
Subsequent ifstream open fails for short files with no end-of-line (EOL)
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: gcc3 (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-12 14:31 EDT by Arthur Person
Modified: 2007-04-18 12:54 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Arthur Person 2003-06-12 14:31:16 EDT
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
--enable-__cxa_atexit
 --host=i386-redhat-linux
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.open("junk3eol.txt");
  ou2 << "-99" << endl;
  ou2.close();
  ou2.open("junk3noeol.txt");
  ou2 << "-99";
  ou2.close();

  // 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
     //in2.open("junk3eol.txt");
     //File with 3 characters and no end-of-line
     in2.open("junk3noeol.txt");
     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;
     }
     in2.close();
     cout << "String read is: " << s << endl;
  }

}


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

How reproducible:
Always

Steps to Reproduce:
1.Run included code
2.
3.
    

Actual Results:  The error was produced.

Expected Results:  Code should have returned the data when the end-of-file was
reached.

Additional info:
Comment 1 Arthur Person 2003-06-17 11:13:35 EDT
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 12:04:42 EDT
That's what you should do.
This behaviour is mandated by ISO C++98.
Comment 3 Arthur Person 2003-06-17 14:58:07 EDT
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.