Hacker News new | ask | show | jobs
by xorblurb 3286 days 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...) ]

1 comments

Actually, 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 .