This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/11584] ios::iword() fails to zero-initialize storage on failure
- From: "ehrhardt at mathematik dot uni-ulm dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Jul 2003 16:56:57 -0000
- Subject: [Bug libstdc++/11584] ios::iword() fails to zero-initialize storage on failure
- References: <20030718231013.11584.sebor@roguewave.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11584
ehrhardt at mathematik dot uni-ulm dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2003-07-29 16:56:56
date| |
Version|3.2 |3.3
------- Additional Comments From ehrhardt at mathematik dot uni-ulm dot de 2003-07-29 16:56 -------
I think I can confirm this. 27.4.2.5 states about the iword function:
| Returns: On success iarray[ idx]. On failure, a valid long&
| initialized to 0.
Currently _M_grow_words returns a reference to _M_word_zero which is
initially set to zero but there is no guarantee that this continues
to be the case. The solution is to set _M_word_zero to 0 in _M_grow_words
before returning a reference to it.
This is ok because p2 states:
| The reference returned may become invalid after another call to the
| object's iword member with a different index, after a call to its
| copyfmt member, or when the object is destroyed.
I'll attach a proposed patch that should fix this. However, I can't
regtest 3.4 at the moment due to libiconv Problems with the testsuite.