Depressing and faintly terrifying days for the C standard [pdf]
At Microsoft the compiler team (Visual C++) and the Windows team are joined at the hip. I&#x27;m sure the same was true at Sun. This can lead to good decisions about undefined behavior that I hope would make Linus smile.<p>I recently learned of one such good engineering decision (I hope I&#x27;m remembering it correctly). Let&#x27;s say you have a struct with an int32 and a byte in it. That&#x27;s 5 bytes, right? But the platform alignment is a multiple of 4 bytes, so there&#x27;s 3 bytes of padding (sizeof the struct is 8 bytes). If we stack-allocate an array of 11 of these and zero-initialize with = { 0 }, what would you expect to see in memory after initialization?<p>It turns out the answer <i>was</i> that the first element of the array would have its 5 bytes zeroed, but the 3 bytes of padding would be left uninitialized. Then, the remaining 10 elements of the array would be zeroed with a memset that actually zeroed all 80 remaining bytes. It sounds weird but this is a legal thing to do from the standard&#x27;s perspective. All they&#x27;re obligated to zero out are the non-padding bytes. This UB was leading to disclosure of little bits of kernel memory back into user mode because Windows engineers assumed that = { 0 } was the same as leaving the variable uninitialized and then memsetting the whole thing to zero. Nope!<p>The compiler team fixed this by always zeroing out padding too. Problem solved. There are some cases where it&#x27;s not quite as fast. But it&#x27;s the right engineering decision by the compiler team for their customers, both internal and external.