Re: zero-alloc cache (was Re: [v3] Fix PR libstdc++/10276)

[Jerry Quinn <jlquinn at optonline dot net>]

Jerry Quinn writes:
> There is also another issue flagged by valgrind, but I
 > don't know what it is from:
 > 
 > 
 > ==31788== 2304 bytes in 2 blocks are possibly lost in loss record 2 of 2
 > ==31788==    at 0x401651B8: malloc (vg_clientfuncs.c:103)
 > ==31788==    by 0x808B1BE: operator new(unsigned) (in /home/jlquinn/gcc/test/a.out)
 > ==31788==    by 0x8079996: std::__new_alloc::allocate(unsigned) (in /home/jlquinn/gcc/test/a.out)
 > ==31788==    by 0x80795DE: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /home/jlquinn/gcc/test/a.out)


With the patch in
http://gcc.gnu.org/ml/libstdc++/2003-04/msg00443.html, I still have
the above issue.  I went ahead and remove strings from the locale
cache, using a wrapper around string buffers.  Even after doing that,
I still have the above allocations.

I finally traced this to __locale_cache:_M_init.  When 
filling out the cache, there is a call to numpunct::truename(), which
is required to create a temporary string.  In general, this can't be
bypassed, because it calls a virtual function that does an unknown
computation to generate this string.  Only if there is no subclassing
can we avoid the creation of the string here.

To get around this, we either have to trash the cache (I REALLY hope
this doesn't happen), or restrict zero alloc to posix locale and hope
for the best.

At this point, I'm stymied.  Help?  

Jerry