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 I bet the compiler will still find a way to mess up your padding bytes. The only safe way are packed structs (not standardized though, but all C/C++ compilers support it).

@floooh @lritter @greenmoonmoon Yeah, surrounding the structs you want this on with:

#pragma pack(push, 1)

// structs

#pragma pack(pop)

That's right, right? Been a while since I learnt about that.

@miblo @lritter @greenmoonmoon ah right, that actually works across gcc/clang and msvc, alignment used to be compiler-specific, but at least in C it has been standardized since C11 (don't know about C++).
@floooh @miblo @greenmoonmoon i need a method that doesn't come out of a preprocessor directive, because i set up the relevant structs by macro already
@lritter @floooh @miblo @greenmoonmoon build with -Wpadded.

@pkhuong @floooh @miblo @greenmoonmoon these are not manually set up structs - they appear through the nudl codegen.

so i would have to ban unaligned table column configurations, and the only reason i could state for this is "because i am incompetent".

if i have no other course of action, i'll have to rewrite the relevant bits of stb_ds to use my macro type dispatch stuff. it's ok. just more work. 🫥

@lritter @pkhuong @miblo @greenmoonmoon for code-generated structs in the sokol shader compiler (to map GLSL structs with 'custom alignment' to C structs) I just use explicit padding bytes inside packed+aligned struct declarations... e.g. like this:
@floooh @pkhuong @miblo @greenmoonmoon it's easier for me to modify stb_ds than to add size/alignment knowledge to the compiler frontend (so far i have managed to avoid this).
@lritter @floooh @miblo @greenmoonmoon as long as you're OK with 0-sized arrays, I'm pretty sure you could have the C compiler figure out how many padding bytes you need after each field (add sizeof, mod alignof).
@pkhuong i don't understand

@lritter Let's say you have struct { int x; char y; double z; };

You'd have

```
enum
{
after_x = alignof(char) - (sizeof(int)) % alignof(char) % alignof(char),
after_y = (alignof(double) - (sizeof(int) + padding_after_x + sizeof(char)) % alignof(double)) % alignof(double),
...
}
```

and tail padding would use `alignof(union { one-of-every-type; })`.

and instead generate `struct {int x; char padding_after_x[after_x]; char y; char padding_after_y[after_y]; double z; char tail_padding[tail];}`.

@pkhuong hm this is indeed possible.