3 ms·

If it is defined as an error, but the compiled build will continue to run with the value wrapped around, I would say that's indistinguishable from UB.

12_throw_away 5mo ago
No. An integer getting deterministically set to an unintended value is a bug. A bug is not the same thing as UB. (Even if it were non-deterministic, it would still not be anything like UB.) It's not the same ballpark, not even the same sport.
- jstimpfle 5mo ago
  What if the wrapped index is used to construct an invalid pointer? It might be possible, not sure. What if the integer is used to read the wrong data from disk, or corrupt data on disk by writing to the wrong location?
  - 12_throw_away 5mo ago
    > What if the wrapped index is used to construct an invalid pointer? Constructing an invalid pointer in rust is UB, yes, but integer wraparound is not. > What if the integer is used to read the wrong data to a disk, or corrupt data on disk by writing to the wrong location? Then it is a very bad bug. > What if the program controls a nuclear power plant and the integer causes the control system to fail, causing memory errors due to radiation from the meltdown? Then it is a very very bad bug. > What if the wrapped integer causes the program to output the true name of god, and the programmer, in their last minutes of existence, looks up to see, overhead, without any fuss, the stars going out? Ok, you got me, this one is UB.
    - kobebrookskC3 5mo ago
      > Constructing an invalid pointer in rust is UB no, it is dereferencing, not constructing, an invalid pointer, that is UB. there is even a safe function provided to construct an invalid but non-null pointer: `https://doc.rust-lang.org/stable/std/ptr/fn.dangling.html https://doc.rust-lang.org/stable/std/ptr/fn.dangling.html`
      - 12_throw_away 5mo ago
        you're of course 100% right, I was so proud of my nerd joke that I got like the most basic rust safety rule wrong :(
  - steveklabnik 5mo ago
    > What if the wrapped index is used to construct an invalid pointer? Using that pointer would be UB, but that is UB, not the addition. > What if the integer is used to read the wrong data from disk, or corrupt data on disk by writing to the wrong location? That is a bug, but it is not undefined behavior.
SAI_Peregrinus 5mo ago
It's indistinguishable from unspecified behavior, not from undefined behavior. Unspecified behavior has to pick from a finite list of allowed behaviors. Undefined behavior can do anything.
- jstimpfle 5mo ago
  A program with corrupted state can essentially do anything. Yes it's still a question of run-time checks the runtime has to protect against it. But the compiler is probably deriving a lot of assumptions from the assumption that there wasn't overflow.
  - steveklabnik 5mo ago
    “Undefined behavior” is a term of art in programming languages that means something more specific than “the program may do something odd.” The compiler is not allowed to derive any assumptions from it. It only could if it were UB.
    - jstimpfle 5mo ago
      But did the rust compiler assume that the integer would not overflow? It did so in Debug mode where runtime checks were added. If it's not the case in Release mode, does that mean semantics are different between Debug and Release?
      - SAI_Peregrinus 5mo ago
        The semantics are well-defined in both modes. You can predict exactly what will happen in either case. In C, the semantics are not defined at all, you can't predict what will happen and it's allowed to change between compilations of the same source. It will probably get omitted, since Undefined Behavior isn't allowed by the C abstract machine, but sadly compilers are allowed to emit code for UB in the source (partly because some UB is only detectable at runtime). Sometimes disabling optimizations will incorrectly allow codegen to run for source lines which have UB, tricking people into thinking that optimizations are breaking their program. Compilers are allowed to do this, since behaviors other than "omit the offending statement" are unfortunately allowed by the standard, so it's not a compiler bug.

12_throw_away 5mo ago

No. An integer getting deterministically set to an unintended value is a bug. A bug is not the same thing as UB. (Even if it were non-deterministic, it would still not be anything like UB.) It's not the same ballpark, not even the same sport.

jstimpfle 5mo ago
What if the wrapped index is used to construct an invalid pointer? It might be possible, not sure. What if the integer is used to read the wrong data from disk, or corrupt data on disk by writing to the wrong location?
- 12_throw_away 5mo ago
  > What if the wrapped index is used to construct an invalid pointer? Constructing an invalid pointer in rust is UB, yes, but integer wraparound is not. > What if the integer is used to read the wrong data to a disk, or corrupt data on disk by writing to the wrong location? Then it is a very bad bug. > What if the program controls a nuclear power plant and the integer causes the control system to fail, causing memory errors due to radiation from the meltdown? Then it is a very very bad bug. > What if the wrapped integer causes the program to output the true name of god, and the programmer, in their last minutes of existence, looks up to see, overhead, without any fuss, the stars going out? Ok, you got me, this one is UB.
  - kobebrookskC3 5mo ago
    > Constructing an invalid pointer in rust is UB no, it is dereferencing, not constructing, an invalid pointer, that is UB. there is even a safe function provided to construct an invalid but non-null pointer: `https://doc.rust-lang.org/stable/std/ptr/fn.dangling.html https://doc.rust-lang.org/stable/std/ptr/fn.dangling.html`
    - 12_throw_away 5mo ago
      you're of course 100% right, I was so proud of my nerd joke that I got like the most basic rust safety rule wrong :(
- steveklabnik 5mo ago
  > What if the wrapped index is used to construct an invalid pointer? Using that pointer would be UB, but that is UB, not the addition. > What if the integer is used to read the wrong data from disk, or corrupt data on disk by writing to the wrong location? That is a bug, but it is not undefined behavior.

SAI_Peregrinus 5mo ago

It's indistinguishable from unspecified behavior, not from undefined behavior. Unspecified behavior has to pick from a finite list of allowed behaviors. Undefined behavior can do anything.

jstimpfle 5mo ago
A program with corrupted state can essentially do anything. Yes it's still a question of run-time checks the runtime has to protect against it. But the compiler is probably deriving a lot of assumptions from the assumption that there wasn't overflow.
- steveklabnik 5mo ago
  “Undefined behavior” is a term of art in programming languages that means something more specific than “the program may do something odd.” The compiler is not allowed to derive any assumptions from it. It only could if it were UB.
  - jstimpfle 5mo ago
    But did the rust compiler assume that the integer would not overflow? It did so in Debug mode where runtime checks were added. If it's not the case in Release mode, does that mean semantics are different between Debug and Release?
    - SAI_Peregrinus 5mo ago
      The semantics are well-defined in both modes. You can predict exactly what will happen in either case. In C, the semantics are not defined at all, you can't predict what will happen and it's allowed to change between compilations of the same source. It will probably get omitted, since Undefined Behavior isn't allowed by the C abstract machine, but sadly compilers are allowed to emit code for UB in the source (partly because some UB is only detectable at runtime). Sometimes disabling optimizations will incorrectly allow codegen to run for source lines which have UB, tricking people into thinking that optimizations are breaking their program. Compilers are allowed to do this, since behaviors other than "omit the offending statement" are unfortunately allowed by the standard, so it's not a compiler bug.