This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/10081] basic_ios::_M_cache_locale leaves NULL members in the face of unknown locales
- From: "peturr02 at ru dot is" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Jun 2003 11:00:20 -0000
- Subject: [Bug libstdc++/10081] basic_ios::_M_cache_locale leaves NULL members in the face of unknown locales
- References: <20030314120600.10081.peturr02@ru.is>
- 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=10081
------- Additional Comments From peturr02 at ru dot is 2003-06-30 11:00 -------
Phil Edwards wrote:
> Well, don't say that the members aren't being initialized, because
> they are:
>
> explicit
> basic_ios(basic_streambuf<_CharT, _Traits>* __sb)
> : ios_base(), _M_ctype(0), _M_num_put(0), _M_num_get(0)
> { this->init(__sb); }
>
> (The names of the variables were changed mid-May.)
Revision 1.18 of basic_ios.h had this:
basic_ios() : ios_base()
{ }
but after this checkin:
Fri Mar 28 19:45:44 2003 UTC (2 months, 4 weeks ago) by bkoz=3D20
the constructor reads thus:
basic_ios() : ios_base(), _M_fctype(0), _M_fnumput(0),
_M_fnumget(0)
{ }
So it seems that the bug has been fixed.
> The crash is because _M_ctype is still NULL when op>> is executed,
> leading to a NULL facet argument in __check_facet.
> basic_ios::init makes an attempt to cache the facet, but since
> has_facet is (I expect) false for pod_char, the members are not
> assigned new values.
>
> I don't know what the Right Thing is here.
The reason that the test case still crashes is this:
operator>>(basic_istream&, basic_string&) calls
basic_istream::sentry::sentry() which behaves "as if" it called
use_facet<ctype<char_type> >(getloc()). Since the locale returned by
getloc() does not contain the requested facet, use_facet throws an
exception, and since there is no matching catch block, the program
crashes.
Wether operator>> or the sentry constructor should catch the exception
is the subject of many other bug reports (and DRs). I think this bug
can be closed, but a
try
{
[ ... ]
}
catch (exception) { }=3D20
needs to be added to the testcase if it is added to the testsuite
(probably a good idea, since there are currently very few testcases
for character types other than char or wchar_t).
Regards,
Petur