Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227635 - stdlib problem: open() of ifstream object does not automatically reset flags
Summary: stdlib problem: open() of ifstream object does not automatically reset flags
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc
Version: 4.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-07 07:59 UTC by Sebastian Steiger
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-02-07 08:42:03 UTC


Attachments (Terms of Use)
Code to test (deleted)
2007-02-07 07:59 UTC, Sebastian Steiger
no flags Details

Description Sebastian Steiger 2007-02-07 07:59:57 UTC
Description of problem:
-----------------------

When an ifstream object is used in several open()-close() cycles, it seems to
remember past cycles in the Red Hat gcc version. The bug persists even when
close() is omitted. If close() is followed by a clear() it
works. The problem is related to the following:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409

I previously reported this bug in the gcc-Bugzilla:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30711

The answer was that clear() will not necessarily have to be called in gcc
versions above 4.0.0. Therefore you must correct this.


Version-Release number of selected component: gcc 4.1.0 20060515 (RH 4.1.0-18)

How reproducible: Always


Steps to Reproduce:
1. Compile the attached code using gcc 4.1.0 20060515 (Red Hat 4.1.0-18)
2. Compile the attached code using gcc version 4.0.2
3. Create a file named "filetest.mat" in the directory where you exectude the
binaries
4. Compare the results: They are different

  
Actual results:
(Output from gcc 4.1.0 20060515 (Red Hat 4.1.0-18) compilation)
------------------------------------------------------
Try 1: ifstream-declaration outside loop (not working)
could not open file ./not_existing_directory/filetest.mat
could not open file ./filetest.mat
------------------------------------------------------
Try 2: ifstream-declaration inside loop (working)
could not open file ./not_existing_directory/filetest.mat
could open file ./filetest.mat
------------------------------------------------------

Expected results:
(Output from gcc 4.0.2 compilation)
------------------------------------------------------
Try 1: ifstream-declaration outside loop (not working)
could not open file ./not_existing_directory/filetest.mat
could open file ./filetest.mat
------------------------------------------------------
Try 2: ifstream-declaration inside loop (working)
could not open file ./not_existing_directory/filetest.mat
could open file ./filetest.mat
------------------------------------------------------

Additional info: See the attachment

Comment 1 Sebastian Steiger 2007-02-07 07:59:57 UTC
Created attachment 147541 [details]
Code to test

Comment 2 Jakub Jelinek 2007-02-07 08:42:03 UTC
All RHEL4 gcc4 packages (whether 4.0.x-RH or 4.1.x-RH based) still use
the gcc 3.4.x-RH libstdc++ library and its STL headers.
The reason for that is that GCC 3.4.x/4.0.x/4.1.x/4.2.x use the same libstdc++
SONAME, all use libstdc++.so.6.
And, in GCC 3.4.x I believe this shouldn't change, based e.g. on
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22
that was in effect at that point, there might be RHEL4 programs that legitimely
rely on this.
RHEL5 uses real GCC 4.1.x-RH libstdc++.so.6, so DR 409 is followed there.


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