I'm more a C++ guy so Handmade Hero is quite interesting experience for me to see more C-style approach. I was "analyzing"/ "digging deeper" into approach used in Handmade Hero for memory management, when uint8_t* is casted to some struct* and then dereferenced. From what I understand in general it's undefined behaviour.
http://en.cppreference.com/w/cpp/language/reinterpret_cast
If AliasedType does not satisfy these requirements, accessing the object through the new pointer or reference invokes undefined behavior. This is known as the strict aliasing rule and applies to both C++ and C programming languages.http://cellperformance.beyond3d.c...liasing.html#cast_to_char_pointer
The converse is not true. Casting a char* to a pointer of any type other than a char* and dereferencing it is usually in volation of the strict aliasing rule.
As noted by Pinskla it is not deferencing a char* per se that is specifically recognized as a potential alias of any object, but any address referring to a char object. This includes an array of char objects, as in the following example which will also break the strict aliasing assumption.
So am I understand it correctly that this is measured risk? Since compiler optimisations from Mike Actons' article shouldn't play here and due to how compilers handle it in reality.
P.S. I found out from one article that sometime ago MSVC wasn't doing strict aliasing optimisation. So it's even less a problem. Yet it's more like understanding question is such work with memory allowed guaranteed by standard or it's how compilers work?