https://bugs.winehq.org/show_bug.cgi?id=48174
--- Comment #46 from Rafał Mużyło galtgendo@o2.pl --- So, first thing: comment 42 is obviously bogus - the first chunk changes boehm - my bad, as I've looked at it, I've missed that I've scrolled that bit off view.
boehm does aligning too, though in arch-dependent way: 8 on 32bit, 16 on 64bit (twice the length of a pointer) - unfortunately, that's kind of hardcoded in the lib (gc_tiny_fl.h).
Still, the test from comment 23 looked promising, up until this bit: "I don't think it breaks until mono reuses memory".
Heisenbugs are nasty...
OK, slightly longer explanation: I got a thing or two wrong; more exactly I've switched the order.
So, to cut the chase, null-gc might not be aligning after all. sgen_alloc_obj_nolock does align, so mono_gc_alloc_vector in metadata/sgen-mono.c falls under this uncertainty.
Somewhat interesting might be that mono_array_new_full_checked does align arrays, but not vectors - then again mono_array_new_specific_internal doesn't align at all...
If not for the fact that I'd not simply need mono, but most likely one built for Windows to compile to Windows executables, I'd likely would give in at this point and just install it to do some testing on my own - no matter how much I dislike the language (well, more the pretense it's cross-platform, when it's not quite so).
Trying to tackle internal implementation details sucks.