"POD" is the wrong type trait to determine if something can be safely
zero-filled in order to achieve zero initialization. Consider a type
like
struct POD { int POD::*ptr; };
This is a POD; its value initialization needs to value initialize the
member, and since it's a pointer, that's zero initialization, and that's
setting the pointer to null.
On Itanium, a null pointer to data member is not zero filled; it actually
has the value -1u.
Hence, zero-filling via memset(0) a POD object like the one above is
erroneous. Unfortunately there is no type trait in C++ that we can use to
know if a given datatype can be value initialized by zero-filling -- we
can check for trivial constructability, but that's a necessary
condition, not a sufficient one (POD above is also trivially
constructible).
The test is disabled on MSVC because of a compiler bug.
Fixes#238
A similar problems for the above (i. e. non-atomic) branch was addressed in #148, yet the default C++11 branch causes segault with the following stacktrace:
```
(gdb) bt
#0 0x000000000e1c3d28 in boost::container::pmr::memory_resource::allocate (this=0x0, bytes=92, alignment=4)
at boost/container/include/boost/container/pmr/memory_resource.hpp:48
#1 0x000000000e2e9e59 in boost::container::pmr::polymorphic_allocator<float>::allocate (this=0x7fffffffd148, n=23)
at boost/container/include/boost/container/pmr/polymorphic_allocator.hpp:92
#2 0x000000000e2e9cdd in std::__y1::allocator_traits<boost::container::pmr::polymorphic_allocator<float> >::allocate (__a=..., __n=23)
at libcxx/include/__memory/allocator_traits.h:262
#3 0x000000000e2e9b13 in std::__y1::vector<float, boost::container::pmr::polymorphic_allocator<float> >::__vallocate (this=0x7fffffffd130, __n=23)
at libcxx/include/vector:958
#4 0x000000000e33c591 in std::__y1::vector<float, boost::container::pmr::polymorphic_allocator<float> >::vector (this=0x7fffffffd130, __n=23)
at libcxx/include/vector:1106
```
