Re: Building a C++ program with -D__USE_MALLOC

["Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> You're missing the point, Martin.  The default allocator does not call
> __builtin_new directly, rather, it uses __default_alloc_template,
> so that if it is used, some Purify errors (eg array-out-of-bounds) will
> be missed, since many allocations will share one malloc/new call.

Oh, I see. Thanks for pointing that out.

> It is really too bad that the default allocator gets wired in to the name
> mangling of the string type.  One possibility that I haven't tried
> (which will break link compatibility, unfortunately), is to modify
> stl_alloc.h to make "alloc" a derived class, rather than a typedef.
> (This handling of the default allocator in libstdc++ v2 is nonstandard
> anyway).

It seems to me that setting __USE_MALLOC will break binary
compatibility, no matter how clever you attempt to do it.

For example, a std::vector instantiation now does not show the
allocator used in its mangled name, e.g.

_._t12_Vector_base2ZiZt9allocator1Zi 
_Vector_base<int, allocator<int> >::~_Vector_base(void)

This is the same whether __USE_MALLOC is defined or
not. Unfortunately, instantiating the vector results in an
instantiation of

_M_deallocate__t18_Vector_alloc_base3ZiZt9allocator1Zib1PiUi
_Vector_alloc_base<int, allocator<int>, true>::_M_deallocate(int *, unsigned int)

If __USE_MALLOC, then this in turn gives you

  call deallocate__t12simple_alloc2ZiZt23__malloc_alloc_template1i0PiUi
  ;simple_alloc<int, __malloc_alloc_template<0> >::deallocate(int *, unsigned int)
  
Otherwise, it is

  call deallocate__t12simple_alloc2ZiZt24__default_alloc_template2b1i0PiUi
  ;simple_alloc<int, __default_alloc_template<true, 0> >::deallocate(int *, unsigned int)

This is not surprising, because there is no polymorphism here - hence
no chance to replace things at run time.

I could hope for two different solutions: On the one hand, Purify may
be able to learn about standard allocators. I believe it is quite
flexible in recognizing memory allocation functions, although I have
not tried adding some. 

On the other hand, you would recompile everything with __USE_MALLOC -
perhaps that could be simplified with another multilib variant
(although a separate compiler installation would probably be easier).

Regards,
Martin