OK, if it is not we who are supporting it :) Yes, you can create a separate instance of memory allocator for unsafe objects. Disable addition of redzones for such unsafe allocations. Asan allocator occupies a continuous region of virtual memory. So in free you can just look at address value to understand that it comes from the unsafe allocator (no need for any flags), in such case you just free it directly to the unsafe allocator. Looks pretty simple. Large allocations are handled slightly differently -- there is no continuous region of virtual memory for them. So probably you can just disable addition of redzones, poisoning and quarantine for them. But otherwise use the same large object allocator. This will require a header to store the safe/unsafe flag for large objects.
On Tue, Dec 23, 2014 at 2:30 PM, Jonas Wagner <[email protected]> wrote: > Hi, > >> Memory-safety is not a property of a library. > > > I can see your concerns. They are valid, but I still like the idea of being > selective. For the moment, just believe me that I do have use cases :) > >> For now it looks like a practically >> uninteresting case to support. > > > Note that I'm not requesting a new ASan feature that would need support. > Instead, I have a (crazy, maybe) idea of something that could be built using > ASan. I don't know yet how to build it... But you, the ASan experts, have > valuable knowledge about this, and I'd love to hear your thoughts. > > Cheers, > Jonas > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
