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

[Nathan Myers]

On Fri, Apr 04, 2003 at 10:10:30PM -0500, Jerry Quinn wrote:
> 
> Benjamin Kosnik <bkoz at redhat dot com> writes:
> > >__locale_cache<num_put<char> >& __lc = use_cache<num_put<char> >
> > 
> > Like this.

I don't see any need to have separate caches per facet.  Indexing it
by character type seems simpler, faster, and sufficient.

Remember that the main use for these caches is for iostream support.
An iostream only needs to know about char, wchar_t, and _CharT details.

> > >I would think that either way, at some point the size of the cache
> > >has to be fixed.  Wouldn't it affect the ABI?
> > 
> > Maybe. I'm unsure. If it doesn't have to be exported, then size won't
> > matter.
> > 
> > >Or are you thinking that the issue is that caches for different facets
> > >can be added later?
> > 
> > This. Would be nice, don't you think?

Even if it is exported, it doesn't matter if inlines aren't affected
and nobody derives from it.  
 
> This sounds like a good approach to me.  Unless I'm mistaken, though,
> we can't do it in 3.3, without losing ABI compatibility.  We would
> have to add another list to the locale::_Impl object to store caches,
> right?
> 
> It occurs to me that 3.3 can still be rescued by hanging the array of
> locale caches off the ios_base::pword(0) pointer.  This would be an
> array for a particular locale - changing the ios_base locale will
> change the array.  It would be refcounted and accessed with a
> use_cache accessor.
> 
> For mainline, the same list will instead live in locale::_Impl.

I don't think that's necessary.  Unless I'm severely mistaken, all 
uses of locale::_Impl that care about its size are in non-template
code in the library proper.  As long as the cache pointer appears
after the existing fields, there should be no ABI problems.

Nathan Myers
ncm-nospam@cantrip.org