[PATCH] Intercept allocation to skim allocated types

Richard Smith richard at metafoo.co.uk
Wed Jan 30 16:29:24 PST 2013


On Wed, Jan 30, 2013 at 10:27 AM, John McCall <rjmccall at apple.com> wrote:
> On Jan 30, 2013, at 2:42 AM, Dai MIKURUBE <dmikurube at acm.org> wrote:
>>  Hello, what do you think about it, John and Richard?
>
> To be frank, the more I look at it, the more this seems like a very questionable language extension.  It adds a lot of linguistic and implementation complexity to some already-quite-complex parts of the language and implementation, all to benefit the approximately 0% of users that will know about and enable the feature.
>
> My understanding is that you'd just like to be able to track what types are being allocated.  Perhaps it would be better to replace operator new, record return addresses, and then somehow map those back to source code?

My biggest concern here is that this extension won't do what you want,
and won't be helpful for anyone else either. That's because it assumes
that new and delete expressions are paired, which is simply false
(even for a leak-free program), because it instruments placement new
and class-specific operator new/delete. For instance:

  {
    char buffer[4];
    new (&buffer) int;
    // no corresponding operator delete call
  }

This will be overwhelmingly common within containers.

If you were suggesting a mechanism to implicitly pass a type_info
object to a global operator new, and to prefer that operator new in
overload resolution, I think I would find that simple and useful
enough to support. But the proposed approach does not seem generally
useful.




More information about the cfe-commits mailing list