4 ms·

Turning all UB into IB would be better so a compiler can provide --overflow=crash or --overflow=wrap.

by liiisalong 4y ago

olliej 4y ago
IB?
- flohofwoe 4y ago
  Implementation defined behaviour.
- matthews2 4y ago
  Implementation defined behaviour
  - olliej 4y ago
    Ah yeah, "unspecified behaviour" is my known phrase, but I can see it would be confusing to be arguing about whether something should be UB or UB :D
    - planede 4y ago
      Unspecified behavior and implementation defined behavior are distinct in theory. The latter requires the behavior to be documented by the implementer, while the former does not. In practice I dare you to find compiler documentation for each implementation defined behavior. https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.unspecified https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.u... https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.impl.defined https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.i... edit: C wording: https://cigix.me/c17#J.1 https://cigix.me/c17#J.1 https://cigix.me/c17#J.3 https://cigix.me/c17#J.3
      - gpderetta 4y ago
        > In practice I dare you to find compiler documentation for each implementation defined behavior. For gcc there is this: https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html No idea how complete it is. Also a lot of stuff is architecture/platform specific, not compiler specific, so you won't find it in the general compiler docs but you have to look at the psABI.
planede 4y ago
UB does not prevent that. Compilers already have flags for those, for example gcc's -ftrapv and -fwrapv .
- gpderetta 4y ago
  in fact it is exactly UB that allows that. If, say, the standard specified wrap behaviour, a conforming compiler wouldn't be allowed to trap.
  - planede 4y ago
    You are right, but OP asserted that IB (implementation defined behavior) would be needed for this. IB would also allow this, but it is not necessary. All of undefined/unspecified/implementation-defined allows this. edit: Whether unspecified or implementation-defined would allow trap depends on the exact wording. If the wording is along the lines of "[on overflow] the value of the expression is unspecified/implementation-defined" then trap is not allowed. But it can be also "[on overflow] the behavior of the program is implementation-defined", which would also allow trap. Point being, unspecified/implementation-defined also have a defined scope, while undefined behavior always just spoils the whole program. I'm fine with the UB overflow though.
    - saagarjha 4y ago
      > the behavior of the program is implementation-defined You're basically defining undefined behavior. The way to do this "properly" would be "the program is allowed to do x, y, z, or also trap"–there's really not much else you can do.
      - gpderetta 4y ago
        Well, it is not that easy. Specifying a subset of allowed outcomes might still prevent future evolution. For example bound checking, while fairly cheap for serial code, makes it very hard to vectorize code effectively. Then again so does IEEE FP math and that's why we have -ffast-math... In the end, it is not impossible, it is just tradeoffs. I'm generally on the opinion that there should be as little UB as possible, but probably this is better done by compilers that can push the limit of static and dynamic checking technology instead of the standard mandating it.

Turning all UB into IB would be better so a compiler can provide --overflow=crash or --overflow=wrap.

olliej 4y ago

IB?

flohofwoe 4y ago
Implementation defined behaviour.
matthews2 4y ago
Implementation defined behaviour
- olliej 4y ago
  Ah yeah, "unspecified behaviour" is my known phrase, but I can see it would be confusing to be arguing about whether something should be UB or UB :D
  - planede 4y ago
    Unspecified behavior and implementation defined behavior are distinct in theory. The latter requires the behavior to be documented by the implementer, while the former does not. In practice I dare you to find compiler documentation for each implementation defined behavior. https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.unspecified https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.u... https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.impl.defined https://timsong-cpp.github.io/cppwp/n4868/intro.defs#defns.i... edit: C wording: https://cigix.me/c17#J.1 https://cigix.me/c17#J.1 https://cigix.me/c17#J.3 https://cigix.me/c17#J.3
    - gpderetta 4y ago
      > In practice I dare you to find compiler documentation for each implementation defined behavior. For gcc there is this: https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html No idea how complete it is. Also a lot of stuff is architecture/platform specific, not compiler specific, so you won't find it in the general compiler docs but you have to look at the psABI.

planede 4y ago

UB does not prevent that. Compilers already have flags for those, for example gcc's -ftrapv and -fwrapv .

gpderetta 4y ago
in fact it is exactly UB that allows that. If, say, the standard specified wrap behaviour, a conforming compiler wouldn't be allowed to trap.
- planede 4y ago
  You are right, but OP asserted that IB (implementation defined behavior) would be needed for this. IB would also allow this, but it is not necessary. All of undefined/unspecified/implementation-defined allows this. edit: Whether unspecified or implementation-defined would allow trap depends on the exact wording. If the wording is along the lines of "[on overflow] the value of the expression is unspecified/implementation-defined" then trap is not allowed. But it can be also "[on overflow] the behavior of the program is implementation-defined", which would also allow trap. Point being, unspecified/implementation-defined also have a defined scope, while undefined behavior always just spoils the whole program. I'm fine with the UB overflow though.
  - saagarjha 4y ago
    > the behavior of the program is implementation-defined You're basically defining undefined behavior. The way to do this "properly" would be "the program is allowed to do x, y, z, or also trap"–there's really not much else you can do.
    - gpderetta 4y ago
      Well, it is not that easy. Specifying a subset of allowed outcomes might still prevent future evolution. For example bound checking, while fairly cheap for serial code, makes it very hard to vectorize code effectively. Then again so does IEEE FP math and that's why we have -ffast-math... In the end, it is not impossible, it is just tradeoffs. I'm generally on the opinion that there should be as little UB as possible, but probably this is better done by compilers that can push the limit of static and dynamic checking technology instead of the standard mandating it.