[vlovich123]

In hot paths it can be even more. This is why even Rust defines it as wrapping but elides the overflow panic in release builds.

[steveklabnik]

It is defined as an error. That error’s default handling is wrapping when debug_assertions is off, and panic when it’s on, but since it’s an incorrect program (though not UB) either behavior is acceptable in any mode.

[jstimpfle]

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]

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]

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]

> 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]

> 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`

[steveklabnik]

> 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]

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]

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]

“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]

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?

[saagarjha]

Yeah on average. On some paths it's almost free