something that worries me is padding in hashmap key types. a while back i experienced a nasty surprise when i discovered clang to optimize copy operations around unused bytes in structs, causing padding to contain uninitialized memory and thus messing up hashes.

#devlog #C

@lritter is it possible to put all hashmap related function in the same translation unit and compile the object file with different optimization level than the rest of the project before linking?
That sounds like a pain to manage but I'm curious if that would work

@greenmoonmoon that wouldn't be the level at which i would counteract it, as it's quite fragile to maintain.

better would be to explicitly memclear a buffer then init the fields in it - before passing the key to any hashmap function. at least that's my plan when i encounter this again.

@lritter @greenmoonmoon If you modify the struct, the padding might change again (e.g. because the compiler promoted a 16 bit store of a field to a 32 bit store of a field and the neighboring padding).