3 ms·
The contents of padding are unspecified after a write; reading it is not UB. Essentially: the padding belongs to the member, and after you initialized the membe
by dom0 9y ago
The contents of padding are unspecified after a write; reading it is not UB. Essentially: the padding belongs to the member, and after you initialized the member the padding is initialized as well (you just don't get any guarantee of the value).
This is the reason why padding for wire formats has to be made explicit and be explicitly initialized, otherwise the compiler is free to generate code packing bible quotes into the padding.
- xorblurb 9y ago> The contents of padding are unspecified after a write; reading it is not UB. Ok so like I said: "depending of the [effective] type maybe reading an uninitialized byte will be UB, or maybe not, depending of how that byte was in a field of a type or just alignement... " If I understand correctly this is so insane (to treat those that are UB in that context as effectively UB) that I still have no word. I absolutely do not want to use a compiler made by people who consider that that situation is OK or even just tolerable for potential gains, regardless of the speedup you could obtain (even at 1000%, I just don't want it -- the risks are way too high) EDIT: I reread and I think I misunderstood. This is not as bad as I thought, but this is extremely complex and I guess compiler bugs will happen (or have already?) in this area. [ Also what is the relationship with extensions? (like pre-standard or even standard explicit extra alignments...) ]
- vyodaiken 9y agoActually, it's even more ridiculous than that. Reading with a char * is UB. Reading with an unsigned char is not. Why? Because the C90 standard made it impossible to write memcpy in C so the committee added a hack for unsigned char .