2. The poster’s job is to work on defining unsafe Rust, where UB is still a thing. It has to be, to some degree, as that’s the entire point.

3. Miri, references in the post, is an interpreter for the Rust abstract machine (or will be, once we’re done defining it) and gives warnings for many kinds of UB already. The hope is that it will be able to do so for all of it in the future. Doing so means defining what “all of it” means, and that’s still in progress.

"This program relies on user input, which is undefined behavior."

Any code that handles signed integers is going to assume that overflow/underflow does not happen.

Should the following code have a warning? It has undefined behavior if argc == 0.

  int main(int argc, char **argv) {
      return **argv;
  }

> refuse to compile/use implementation-defined behaviour (i.e. exactly "what the hardware does")

malloc is guaranteed to be 16-byte aligned on macOS. Should the following code not compile?

  void *memalign(size_t size, size_t alignment) {
  #if TARGET_OS_MAC
      if (alignment < 16) {
          return malloc(size);
      }
  #endif
      // General case
  }

Undefined behavior is, for the most part, meant to enable compiler optimizations. If you're willing to do all your optimizations by hand rather than relying on the compiler to do them – in other words, use C as the "portable assembler" it was originally conceived as – then you don't really need it. (At least, not to the extent it exists in C.) And for small, tight loops, that's a perfectly reasonable proposition. For large programs, on the other hand, especially if you want to pile on a lot of abstraction and rely on the compiler to turn it into nice code (see C++)... not so much.

"couldn't possibly be rewritten" isn't always the issue; sometimes you need to improve the toolchain and language to provide a supported non-undefined solution, for instance.