fixing std::shared_ptr<void> initialization from void*

[MiguelBarro]

class shared_ptr is optimized to avoid keeping a deleter object for non-primitive types which are detected using _Can_scalar_delete. This class relies on SFINAE to detect if the operator delete is valid for a given pointer type. It turns out that delete a void* is valid in msvc, though, according to the standard is undefined behaviour (7.6.2.9). By specializing for void is possible to prevent direct initialization of shared_ptr<void> from a void* and prevent bugs. Note that default_deleter<void> is not valid too.

[achabense]

Is this a compiler bug?

#include <memory>

constexpr int foo() {
  void* p = new int;
  delete p;
  return 0;
}

int main() { constexpr auto f = foo(); }

/std:c++14
/std:c++20 my bad

[fsb4000]

Is this a compiler bug?

@achabense , no. We have constexpr new only since C++20. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0784r7.html

[achabense]

Hmm... _Can_scalar_delete

[frederick-vs-ja]

though, according to the standard is undefined behaviour (7.6.2.9)

It seems that the standard wording in [expr.delete] is defective. In the core spec, "shall" generally means that requirements for well-formedness, not for the well-definedness of the behavior. However, "shall" sometimes introduces UB in [expr.delete], and it's not clear whether deleting a void* can be well-formed.

• Clang rejects it when passing -pedantic-errors.
• GCC accepts it with -pedantic-errors, even in constant evaluation since C++20, but says that it's undefined.
• MSVC silently accepts it.

[CaseyCarter]

FYI, I'm calling this "bug" rather than "enhancement" since [util.smartptr.shared.const]/4 says we should be diagnosing this as ill-formed.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

Thanks for fixing this bug and congratulations on your first microsoft/STL commit! 🚀 🎉 🥳