Hacker News Reader

Comment by tomp | Hacker News Reader

This is just terrible. I'm really sad that it's 2019, and not only are we still talking about undefined behaviour, but there are also blog posts arguing for undefined behaviour! I expect a good (programmer-friendly) compiler to at least warn the programmer in any case of provable, or potential, undefined behaviour, or ideally, refuse to compile/use implementation-defined behaviour (i.e. exactly "what the hardware does"). Anything else is basically just inviting security bugs in your code.

But, for a counter-point: what is an example of a code/algorithm that not only uses undefined behaviour (i.e. relies on it in order to compile to fast, optimized code), but also couldn't possibly be rewritten to eliminate undefined behaviour (while keeping the same speed)?

View on HN

1. Safe Rust has no undefined behavior, by design.

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.

> 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."

> But, for a counter-point: what is an example of a code/algorithm that not only uses undefined behaviour (i.e. relies on it in order to compile to fast, optimized code), but also couldn't possibly be rewritten to eliminate undefined behaviour (while keeping the same speed)?

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

Note that this isn’t UB in Rust.

Spent the week trying to figure out how to reimplement __builtin_add_overflow (et al) on Windows and boy is it a chore. The previous implementer had literally just used operator+ in a function called "safe_add" and I was dumbstruck.

> I expect a good (programmer-friendly) compiler to at least warn the programmer in any case of provable, or potential, undefined behaviour

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

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

As you can see, alerting for potential undefined behavior is a very difficult problem to do in a way that doesn't cause a bunch of spurious issues.

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

> but also couldn't possibly be rewritten to eliminate undefined behaviour (while keeping the same speed)?

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.

You mentioned it briefly with "implementation-defined behavior" but tons of C/C++ relies on technically undefined behavior that has normal behavior on standard compiler / platform combinations.

> what is an example of a code/algorithm that not only uses undefined behaviour (i.e. relies on it in order to compile to fast, optimized code), but also couldn't possibly be rewritten to eliminate undefined behaviour (while keeping the same speed)?

"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.

Reply on news.ycombinator.com