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: bkoz at redhat dot com
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Fri, 04 Apr 2003 22:10:30 -0500
- Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
- References: <20030403162601.26100.qmail@sources.redhat.com><16013.38790.714946.483440@gargle.gargle.HOWL>
Benjamin Kosnik <bkoz at redhat dot com> writes:
> >__locale_cache<num_put<char> >& __lc = use_cache<num_put<char> >
>
> Like this.
>
> >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?
>
> -benjamin
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'm presuming this bug is not safe to leave in 3.3.
What do you think?
Jerry