Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Turns out people get upset when their code goes slower because the the compiler added traps on signed overflow.


Don't add traps, just let it overflow and don't fuck up any bounds checks the programmer added.


That's still slower than UB.

With UB compilers can assume that eg 'x + 1 > x' is always true for signed integers. That allows quite a few optimizations.


Why can they assume that? how on earth did "undefined" ever get read as "can not happen"? if the standard meant "can not happen", they would have said "can not happen". but they did not, they said we are not going to define what is going to happen. or in other words, the cpu is going to do something when this happens but we don't know what.

Nothing in there lets the compiler get to say "this will never happen". but they do exactly this.


Because compilers only work with programs that have well-formed executions.


> just let it overflow

I agree with this. Making integer overflow UB is ridiculous.

> and don't fuck up any bounds checks

But I disagree with this. That's just normal UB-based optimization, one of the point of having UB at all is to do such optimization.


Ok well yes, technically as soon as the compiler doesn't treat the overflow as UB anymore the second part is not applicable anymore. Badly worded on my side.


This is bad because few programs are built to deal with two positive numbers being multiplied returning a negative result.


Yet no programs are built to deal with UB... Accidental UB is the curse of modern C.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: