4 ms·
> I can't understand why e.g. use of an uninitialized variable or oversized shift amounts are UB Probably some obscure architecture traps on oversized shifts o
by legulere 11y ago
> I can't understand why e.g. use of an uninitialized variable or oversized shift amounts are UB
Probably some obscure architecture traps on oversized shifts or something similar. To correctly implement it you would first have to check if the shift lies inside the bounds with a branch. Branches are expensive - this is the powerful optimisation.
- tomp 11y agoIf I write if ((1 << 33) == 0) { // whatever } I'm fine with my program crashing. I'm not fine with my compiler simply assuming this cannot happen, and removing the whole `if` statement.
- chrisseaton 11y agoRight but are you also fine if your program runs slower to achieve that? Because that's the trade off in many cases. Slowing programs down with bounds and aliasing checks is not the C philosophy.
- lmm 11y ago> I'm fine with my program crashing. I'm not fine with my compiler simply assuming this cannot happen, and removing the whole `if` statement. What's the difference? Do you mean you don't want your compiler to ever reorder instructions? That would cost a lot of performance. Try to formalize the guarantee that you want the compiler to give in the presence of programs like that, and the reasons for leaving it undefined become a lot more clear.
- tomp 11y ago> Do you mean you don't want your compiler to ever reorder instructions? The compiler's job is making code run faster while preserving intent. If I can write a 33bit shift in ASM, then I should be able to write it in C. How the CPU executes the code is my (the programmer's) business, not the compiler's.