This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
- From: Jerry Quinn <jlquinn at optonline dot net>
- To: paolo at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org,peturr02 at ru dot is, gcc-gnats at gcc dot gnu dot org
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Thu, 03 Apr 2003 09:41:47 -0500
- Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
- References: <20030324131611.28303.qmail@sources.redhat.com>
paolo at gcc dot gnu dot org writes:
> Synopsis: Regression: Segmentation fault in num_put::put
>
> Responsible-Changed-From-To: unassigned->jlquinn
> Responsible-Changed-By: paolo
> Responsible-Changed-When: Mon Mar 24 13:16:11 2003
> Responsible-Changed-Why:
> Jerry, I'm tentatively assigning this one to you: the problem
> appear in your new _M_convert_int and _M_group_int.
> State-Changed-From-To: open->analyzed
> State-Changed-By: paolo
> State-Changed-When: Mon Mar 24 13:16:11 2003
> State-Changed-Why:
> Confirmed 3.3 and 3.4.
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9828
OK, I can see why the crash is happening now. In the test program, we
have:
typedef num_put<wchar_t> npw_t;
wostringstream stream;
const npw_t& npw = use_facet<npw_t>(stream.getloc());
npw.put(stream, cout, L' ', static_cast<long>(10));
In particular, we're calling num_put<wchar_t>::put with
basic_ostream<char>. The printing code pulls the locale_cache from
the ios_base that is provided - in this case, cout. But the code
assumes that the cache provided by ios_base is instantiated with the
same type as the num_put class, and hence that the ios_base is a base
class for an ostream that was also instantiated with that type.
In this failure, cout provides __locale_cache<char>, but we interpret
it as __locale_cache<wchar_t> and things go downhill from there.
This is ugly! To make this work, we need to get
__locale_cache<wchar_t> from somewhere, in sync with the facet being
used for printing.
I'm open to suggestions here. As is, we're trading one regression for
another - and the performance regression without the locale cache
stuff is pretty bad.
One possibility is that ios_base would have to be able to provide a
cache for any type that is asked for - seems ugly.
Another is that locales carry the cache info to avoid this problem.
Or perhaps the facets cache the info required, but that may get into
overlaps of info between facets.
Jerry Quinn