2 ms·

This is great. But why do you care about what that standard says? Making it UB in ISO C ensures that no portable program can rely on a specific behavior and th

by uecker 2y ago

This is great. But why do you care about what that standard says? Making it UB in ISO C ensures that no portable program can rely on a specific behavior and this is what makes it possible to find bugs this way, because it is plausible to assume that a program with overflow is buggy. This is also why this does not work for unsigned. We can easily change a compiler to trap on unsigned wraparound. But this is mostly useless because there would be far too many false positives.

gavinhoward 2y ago
> Making it UB in ISO C ensures that no portable program can rely on a specific behavior This is true. > and this is what makes it possible to find bugs this way No, this is not true. In fact, it is the opposite of true. If a program cannot rely on behavior, it cannot rely on having the behavior that causes the bug to be visible.
- uecker 2y ago
  It does not need to be able to rely on having the behavior that causes the bug to be visible. We just need tools that make the bug visible, e.g. the undefined behavior sanitizers. Those tools work extremely well for signed overflow, but not for unsigned, exactly because unsigned wraparound is defined and for this reason many programs use it. So you can not distinguish between intended wraparound and incorrect wraparound. For this reason, signed overflow is essentially a solved problem, while unsigned wraparound will be the source for many interesting bugs - exactly because it is not UB!
  - gavinhoward 2y ago
    > We just need tools that make the bug visible, e.g. the undefined behavior sanitizers. Does the compiler faithfully compile the source code with sanitizers? Of course not, so we still cannot rely on them. > So you can not distinguish between intended wraparound and incorrect wraparound. This is exactly why I implemented both types in my arithmetic. The one I used is the one I intended.
    - uecker 2y ago
      A compiler which compiles with a sanitizer can be perfectly conforming, i.e. faithfully compile a program.
      - gavinhoward 2y ago
        That is not what I mean. I mean that the compiler follows the programmer's intent.
        uecker 2y ago
        How would a compiler know the programmer's intent?

by uecker 2y ago

gavinhoward 2y ago

> Making it UB in ISO C ensures that no portable program can rely on a specific behavior This is true. > and this is what makes it possible to find bugs this way No, this is not true. In fact, it is the opposite of true. If a program cannot rely on behavior, it cannot rely on having the behavior that causes the bug to be visible.

uecker 2y ago
It does not need to be able to rely on having the behavior that causes the bug to be visible. We just need tools that make the bug visible, e.g. the undefined behavior sanitizers. Those tools work extremely well for signed overflow, but not for unsigned, exactly because unsigned wraparound is defined and for this reason many programs use it. So you can not distinguish between intended wraparound and incorrect wraparound. For this reason, signed overflow is essentially a solved problem, while unsigned wraparound will be the source for many interesting bugs - exactly because it is not UB!
- gavinhoward 2y ago
  > We just need tools that make the bug visible, e.g. the undefined behavior sanitizers. Does the compiler faithfully compile the source code with sanitizers? Of course not, so we still cannot rely on them. > So you can not distinguish between intended wraparound and incorrect wraparound. This is exactly why I implemented both types in my arithmetic. The one I used is the one I intended.
  - uecker 2y ago
    A compiler which compiles with a sanitizer can be perfectly conforming, i.e. faithfully compile a program.
    - gavinhoward 2y ago
      That is not what I mean. I mean that the compiler follows the programmer's intent.
      - uecker 2y ago
        How would a compiler know the programmer's intent?