labath added a comment. In https://reviews.llvm.org/D47492#1122039, @jankratochvil wrote:
> In https://reviews.llvm.org/D47492#1121543, @dblaikie wrote: > > > Happy to help explain it - which part(s) are you having a bit of trouble > > with? > > > What's wrong on this implementation > <https://people.redhat.com/jkratoch/incredibleshrinkingvector.C>? > > > It seems like the main one is that the implementation can't be sure that > > malloc was used to allocate the memory - since the global allocation > > function can be replaced & there's no convenient way to detect that. > > The example above does verify whether the vector uses default libstdc++ > std::allocator which uses libstdc++ ::operator new which uses malloc(). It doesn't look like your code verifies that the user hasn't replaced the global `operator new` by defining a custom version. http://en.cppreference.com/w/cpp/memory/new/operator_new: > The versions (1-4) are implicitly declared in each translation unit even if > the <new> header is not included. Versions (1-8) are replaceable: a > user-provided non-member function with the same signature defined anywhere in > the program, in any source file, replaces the default version. Its > declaration does not need to be visible. The requirement that the declaration need not even be visible makes me believe this is not possible to detect at compile time. This kind of overriding is usually done via weak symbols, and the only way of detecting that I can think of is if libstdc++ exposed a non-weak alias to its `operator new` and then `shrink_to_fit` did a runtime check like `if(&__standard_operator_new == &::operator new)`. That seems like a huge hack. Repository: rL LLVM https://reviews.llvm.org/D47492 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
