Freeing xalloc'ed array

[Akim Demaille]

Hi!

Sorry if this is an FAQ, but I found no information about it.

I'm trying to have 0 memory leak, because that's the easiest means to
be sure you introduce no new leak.  Hence I happily use
GLIBCXX_FORCE_NEW.  But it does not free the xalloc' array in
streams.  I'm tempted to call this a bug: it is up to the user the
free associated memory, but the xalloc'd array is under the
responsibility of the library.

It seems that there are four preallocated slots, but I use more.

For instance:

/tmp % eof xalloc.cc                                             nostromo 17:57
: -------------------- xalloc.cc ----------------------
cat > xalloc.cc << \EOF
#include <vector>
#include <iostream>

int
main ()
{
  const int N = 5;
  std::vector<int> index (N);
  for (int i = 0; i < N; ++i)
    {
      index[i] = std::ios::xalloc ();
      std::cout.iword (index[i]) = 42;
    }
}
EOF
: ------------------------------------------------------------
/tmp % g++ xalloc.cc && v ./a.out                                nostromo 17:57
== Memcheck, a memory error detector for x86-linux.
== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
== Using valgrind-2.2.0, a program supervision framework for x86-linux.
== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
== For more details, rerun with: -v
==
==
== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
== malloc/free: in use at exit: 72 bytes in 1 blocks.
== malloc/free: 2 allocs, 1 frees, 92 bytes allocated.
== For counts of detected errors, rerun with: -v
== searching for pointers to 1 not-freed blocks.
== checked 2390692 bytes.
==
== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==    at 0x1B9052D9: operator new[](unsigned) (vg_replace_malloc.c:139)
==    by 0x1B9678D3: std::ios_base::_M_grow_words(int) (in /usr/lib/libstdc++.so.5.0.7)
==    by 0x80489F5: std::ios_base::iword(int) (in /tmp/a.out)
==    by 0x8048850: main (in /tmp/a.out)
==
== LEAK SUMMARY:
==    definitely lost: 0 bytes in 0 blocks.
==    possibly lost:   0 bytes in 0 blocks.
==    still reachable: 72 bytes in 1 blocks.
==         suppressed: 0 bytes in 0 blocks.



If it is not considered as a bug, what can I do to address this issue?
Thanks in advance!