4 ms·

This is not a bug. This is the model of C. You should blame C not GCC.

by ototot 4y ago

iforgotpassword 4y ago
I blame GCC. The C standards committee is some out of touch with reality conglomerate working in a vacuum, taking 50 years of language history into account. I expect my compiler vendor to be on my side, ie produce a compiler that helps me write good software and not get in my way. GCC is doing the opposite, it's deliberately looking to use the standard to fuck me over in the most subtle and unexpected ways. Signed integer overflow is undefined; that gives compiler authors the liberty to make it do anything they want, including well defined things that anyone would expect and find useful. But GCC decides to fuck you over so their devs can give you an arrogant reply and impose their superiority if you show up on their bug tracker.
- astrange 4y ago
  GCC's developers work for companies that want more optimizations. UB is the way you get these optimizations. But "gcc -fsanitize=undefined" is just as easy to run as "gcc -O3" is.
- saagarjha 4y ago
  Turns out people get upset when their code goes slower because the the compiler added traps on signed overflow.
  - iforgotpassword 4y ago
    Don't add traps, just let it overflow and don't fuck up any bounds checks the programmer added.
    - sanxiyn 4y ago
      > 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.
      - iforgotpassword 4y ago
        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.
    - saagarjha 4y ago
      This is bad because few programs are built to deal with two positive numbers being multiplied returning a negative result.
      - yencabulator 4y ago
        Yet no programs are built to deal with UB... Accidental UB is the curse of modern C.
    - eru 4y ago
      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.
      - somat 4y ago
        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.
        saagarjha 4y ago
        Because compilers only work with programs that have well-formed executions.

This is not a bug. This is the model of C. You should blame C not GCC.

by ototot 4y ago

This is not a bug. This is the model of C. You should blame C not GCC.

I blame GCC. The C standards committee is some out of touch with reality conglomerate working in a vacuum, taking 50 years of language history into account. I expect my compiler vendor to be on my side, ie produce a compiler that helps me write good software and not get in my way. GCC is doing the opposite, it's deliberately looking to use the standard to fuck me over in the most subtle and unexpected ways. Signed integer overflow is undefined; that gives compiler authors the liberty to make it do anything they want, including well defined things that anyone would expect and find useful. But GCC decides to fuck you over so their devs can give you an arrogant reply and impose their superiority if you show up on their bug tracker.

astrange 4y ago
GCC's developers work for companies that want more optimizations. UB is the way you get these optimizations. But "gcc -fsanitize=undefined" is just as easy to run as "gcc -O3" is.
saagarjha 4y ago
Turns out people get upset when their code goes slower because the the compiler added traps on signed overflow.
- iforgotpassword 4y ago
  Don't add traps, just let it overflow and don't fuck up any bounds checks the programmer added.
  - sanxiyn 4y ago
    > 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.
    - iforgotpassword 4y ago
      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.
  - saagarjha 4y ago
    This is bad because few programs are built to deal with two positive numbers being multiplied returning a negative result.
    - yencabulator 4y ago
      Yet no programs are built to deal with UB... Accidental UB is the curse of modern C.
  - eru 4y ago
    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.
    - somat 4y ago
      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.
      - saagarjha 4y ago
        Because compilers only work with programs that have well-formed executions.