libstdc++/4442: bad fstream behavior <synopsis of the problem (one line)>

libstdc++/4442: bad fstream behavior <synopsis of the problem (one line)>

[Andrew Haydn Grant]

>Number:         4442
>Category:       libstdc++
>Synopsis:       bad fstream behavior
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 02 11:56:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Andrew Haydn Grant
>Release:        3.0.1
>Organization:
>Environment:
System: Linux Goof 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /usr/local/src/gcc-3.0.1/configure 
>Description:
fstreams handle certain odd situations differently than they used to,
causing old code to break.

This code contains C++ less-than operators, so I don't know if the bug
program will turn them into comment characters.

void fail()
{
  fstream f;
  f.close();
  f.open("hello.txt", ios::in);
  char buffer[2048];
  f.getline(buffer, 2048);
  cout << "FILE CONTENTS" << buffer << "FILE CONTENTS\n";
}

The fail() function does not read "hello.txt".  If you remove the initial
f.close() call, it reads "hello.txt" without difficulty.

void failWrite()
{
  fstream f;
  f.open("/tmp/empire/simout.txt", ios::in);
  f.close();
  f.open("/tmp/empire/simout.txt", ios::out);
  f << "It went out!!!\n";
}

If the simout.txt file does NOT exist, the second open succeeds, 
but the << operator fails.  If the simout file ALREADY exists, then all 
operations succeed.

	
>How-To-Repeat:
	
>Fix:
To work around the problem, only use a given fstream object for one file operation.  Avoid spurious close() calls.

	
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: libstdc++/4442: bad fstream behavior <synopsis of the problem (one line)>

[Phil Edwards]

The following reply was made to PR libstdc++/4442; it has been noted by GNATS.

From: Phil Edwards <pedwards@disaster.jaj.com>
To: andrew@werdna.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/4442: bad fstream behavior 	<synopsis of the problem (one line)>
Date: Tue, 2 Oct 2001 16:38:04 -0400

 On Tue, Oct 02, 2001 at 02:47:54PM -0400, Andrew Haydn Grant wrote:
 > >Description:
 > fstreams handle certain odd situations differently than they used to,
 > causing old code to break.
 
 The behavior you're seeing is, unfortunately, unspecified by the standard.
 Even more unfortunately, the currently recommended resolution is to
 maintain this behavior.  For more, see the C++ homepage linked to from
 the GCC "Readings" list, and look for LWG defect report 22.
 
 (I /must/ remember to add this to the FAQ...)
 
 
 > void fail()
 > {
 >   fstream f;
 >   f.close();
 >   f.open("hello.txt", ios::in);
 >   char buffer[2048];
 >   f.getline(buffer, 2048);
 >   cout << "FILE CONTENTS" << buffer << "FILE CONTENTS\n";
 > }
 > 
 > The fail() function does not read "hello.txt".  If you remove the initial
 > f.close() call, it reads "hello.txt" without difficulty.
 
 You can place a call to f.clear() between the close() and the open(),
 then it will work.  Also note that this will /not/ display the entire
 contents of hello.txt, only the first line.
 
 
 > void failWrite()
 > {
 >   fstream f;
 >   f.open("/tmp/empire/simout.txt", ios::in);
 >   f.close();
 >   f.open("/tmp/empire/simout.txt", ios::out);
 >   f << "It went out!!!\n";
 > }
 
 Likewise, a call to clear() between open() and close() will make this work
 as you (and the rest of us) expect it to.
 
 Phil
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams