3 ms·

I'm not convinced a "common" C program would ever do such a thing. Even the "Effective C" book (one of the best books on C, imo) discusses why this is wrong and

by zer8k 3y ago

I'm not convinced a "common" C program would ever do such a thing. Even the "Effective C" book (one of the best books on C, imo) discusses why this is wrong and why you should take advantage of `limits.h` for bounds checking. This is just bad programming. The compiler, like usual, is correct because you're not in reality checking anything. You've made an obviously non-sensical statement that the overflowed value will be less than the value. Compiler optimizes it away. You can argue the semantics of UB here but this particular UB is borderline a solved problem in any practical sense. To be fair, a static analyzer should be able to catch this.

_dain_ 3y ago
>You've made an obviously non-sensical statement— Therefore it should fail to compile. You can even spin it as a performance enhancement: the whole program can be optimized away!
- layer8 3y ago
  The problem is, that’s not how the logical inference in a compiler/optimizer works. It’s very difficult to translate such an optimization back to “this statement has been optimized away”, in the general case.
  - _dain_ 3y ago
    If it's so difficult to figure out if the consequences of their optimization game are sensible or not, then they shouldn't play it in the first place. Who actually wants it to behave this way, other than compiler engineers competing on microbenchmarks? Who is this language even for?
    - layer8 3y ago
      It’s a side effect of desirable optimizations for UB-free code. You can’t have both at the same time.
      - _dain_ 3y ago
        Desirable for whom? Are the beneficiaries of it going to pay for the externalities they are generating, like polluters should? You can say "ordinary workaday programmers benefit from speed improvements en passant", but they weren't really given a choice in the matter, were they? When programmers are given an explicit binary choice of "correct, but slightly slower", and "wrong, but slightly faster", they pick the former in practically all cases (or they should, at any rate). But they can't make this choice; the compiler and spec writers go behind their backs and construct these inscrutable labyrinths, then blame everyone else for getting lost in them.
        aidenn0 3y ago
        -fwrapv is there for people to use. People don't use it. Yes defaults matter, but they matter both ways. People benchmark with the default options and a compiler with -fwrapv turned on by default will lose those benchmarks and the "ordinary workaday programmers" still end up with trading correctness for speed, since one person at their workplace ran one benchmark once and picked the compiler that won in speed.

by zer8k 3y ago

_dain_ 3y ago

>You've made an obviously non-sensical statement— Therefore it should fail to compile. You can even spin it as a performance enhancement: the whole program can be optimized away!

layer8 3y ago
The problem is, that’s not how the logical inference in a compiler/optimizer works. It’s very difficult to translate such an optimization back to “this statement has been optimized away”, in the general case.
- _dain_ 3y ago
  If it's so difficult to figure out if the consequences of their optimization game are sensible or not, then they shouldn't play it in the first place. Who actually wants it to behave this way, other than compiler engineers competing on microbenchmarks? Who is this language even for?
  - layer8 3y ago
    It’s a side effect of desirable optimizations for UB-free code. You can’t have both at the same time.
    - _dain_ 3y ago
      Desirable for whom? Are the beneficiaries of it going to pay for the externalities they are generating, like polluters should? You can say "ordinary workaday programmers benefit from speed improvements en passant", but they weren't really given a choice in the matter, were they? When programmers are given an explicit binary choice of "correct, but slightly slower", and "wrong, but slightly faster", they pick the former in practically all cases (or they should, at any rate). But they can't make this choice; the compiler and spec writers go behind their backs and construct these inscrutable labyrinths, then blame everyone else for getting lost in them.
      - aidenn0 3y ago
        -fwrapv is there for people to use. People don't use it. Yes defaults matter, but they matter both ways. People benchmark with the default options and a compiler with -fwrapv turned on by default will lose those benchmarks and the "ordinary workaday programmers" still end up with trading correctness for speed, since one person at their workplace ran one benchmark once and picked the compiler that won in speed.