This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libstdc++/9828: Regression: Segmentation fault in num_put::put


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]