On Tue, Dec 23, 2014 at 1:25 PM, Jonas Wagner <[email protected]> wrote: > Hi, > >> First of all, why would you want to do such thing? >> Do you have a particular use case? > > > It's a justified question. We do have use cases for this. For example, > consider a library that is formally proven to be free from memory errors. We > can already build this library without ASan, so that it won't have checks. > Yet it is still linked with the ASan memory allocator, so its objects have > red zones, compete for quarantine space, etc.
Memory-safety is not a property of a library. Is libc's memcpy safe? Maybe yes, maybe no, depending on the pointers passed from outside. Is std::string safe? Yes. Unless c_str() pointer is leaked to an unsafe C function. A library can be safe iff it does not accept any pointers from outside nor leak any pointer to outside. I have not seen any such libraries. Can you provide any examples? For now it looks like a practically uninteresting case to support. > There are other questions to clarify, like how to separate the unsafe memory > space from the regular program memory. But I think we could solve these in > time when they arrive. For now, I'm looking mostly for ideas about how > unprotected objects could coexist with ASan. > > 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.
