yet another instance of the Windows API making me commit crimes on purpose
// BARK BARK BARK BARK BARK
alignas(::IMAGEHLP_SYMBOL64) std::byte symbol_storage[sizeof(::IMAGEHLP_SYMBOL64) + MAXIMUM_SYMBOL_LENGTH];
::IMAGEHLP_SYMBOL64 *symbol { new (&symbol_storage) ::IMAGEHLP_SYMBOL64 };
- the
IMAGEHLP_SYMBOL64structure uses an array inside itself to hold a string that could be any length (thankfully, it does let you specify the maximum size to truncate to) - more alarmingly, the storage for this array is specified as
CHAR Name[1];in the documentation... that can't possibly be enough to hold an arbitrary-length string, right? unless... - the array is the last field of
struct IMAGEHLP_SYMBOL64... which means the size of the array has to be accounted for by you, when you allocate the object, by adding extra padding bytes after the end... meaning you need to allocate a variable-sized object, which is not something C++ really... has a concept of? - once again, i'm 99% sure this is UB, since these bytes are just kind of floating off in space. as far as the abstract machine is concerned, there's no object occupying that space, so afaik it's fair game for the compiler to use them for whatever it wants, or omit them entirely, or overlap them with another object, ...
this is essentially the same thing as a variable-length array or VLA, a C feature that was so gnarly that C++ just never even standardized them. you can still use VLAs in C++ depending on the compiler, but this particular structure isn't even declared using the typical VLA syntax... it's just, cursed,
as the icing on the cake, this code primarily runs inside my crash handler... it's extracting symbol names from the debug information so i can get a nice looking stack trace 

eggbug enjoyer