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
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc   
(Show other bugs)
Version: 4.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
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:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-07 08:42:03 UTC
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 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.