by averagedev on 2/6/22, 6:54 PM with 3 comments
by JonChesterfield on 2/6/22, 8:48 PM
This can be worked around by putting the allocator in a separate object file (no LTO) or shared library, or by annotating it with compiler attributes that locally switch off aliasing, or by hoping the compiler doesn't exploit the UB inherent in the allocator to your ruin.
Same game in C++ as of the last time I checked, but at least there's placement new and std::launder as workarounds, which strictly speaking need to be used when creating objects with malloc too.
> no actual replacement occurring, rather a simple recasting, since both structs have the same memory footprint
Can't do that either I'm afraid for much the same reason, need to memcpy over the memory and trust the compiler to elide said copy
by averagedev on 2/6/22, 7:48 PM