Bug 227635 - stdlib problem: open() of ifstream object does not automatically reset flags
stdlib problem: open() of ifstream object does not automatically reset flags
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-07 02:59 EST by Sebastian Steiger
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-07 03:42:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Code to test (1.30 KB, application/octet-stream)
2007-02-07 02:59 EST, Sebastian Steiger
no flags Details

  None (edit)
Description Sebastian Steiger 2007-02-07 02:59:57 EST
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 02:59:57 EST
Created attachment 147541 [details]
Code to test
Comment 2 Jakub Jelinek 2007-02-07 03:42:03 EST
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.