On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote: > On 12/04/2013 04:03 PM, Jakub Jelinek wrote: > > I think the most important reason is that we want to handle out of mem > > cases consistently, so instead of malloc etc. we want users to use xmalloc > > etc. that guarantee non-NULL returned value, or fatal error and never > > returning. For operator new that is solvable through std::set_new_handler > > I guess, but for malloc we really don't want people to deal with checking > > NULL return values from those everywhere. > > A simple workaround would be to disable poisoning of malloc/realloc on > OS X (or when the build machine uses libc++, if that's easy to detect).
Whether libc++ uses malloc/realloc/free in some implementation in a header file or not is an implementation detail. It could use it today and stop doing so tomorrow ;) Maybe a configure option to disable the poisoning would be better in this case? Cheers, Oleg
