Compiler Can Undo Your Security Checks (davidbombal.com)

It follows from the definition of UB:

undefined behavior: "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements" The C++ spec at some point changed this to explicitly allow changing anything in the program not just the specific behavior implied by the "for which". The C spec never did this.

Because people were confused about this, in C23 we added the following note. "Note 3 to entry: Any other behavior during execution of a program is only affected as a direct consequence of the concrete behavior that occurs when encountering the erroneous or non-portable program construct or data. In particular, all observable behavior (5.1.2.4) appears as specified in this document when it happens before an operation with undefined behavior in the execution of the program."

Compilers mostly follow this. GCC has bugs related to volatile. Clang often follows the C++ standard, where it is different from C, so probably does not conform to the standard here (as for some other things).

The new C++ standard will have UB "barrier", i.e. std::observable that will limit the effect of UB to things before this barrier.

> Rust UB […] is meant to be limited in blast radius, and is absolutely not meant as a loophole for compilers to just do whatever to make the code faster.

This isn't true. Rust UB is meant to only be possible to trigger via `unsafe` code, but if you do trigger it, the compiler is free to do whatever it wants, and in practice it will make full use of that freedom. Rustc uses LLVM, it shares most of its optimizations with Clang!

C++26 and C++29 are in the process of turning a lot of that UB into erroneous behaviour, basically what safer languages have been doing for ages.

However, how many years it will take until those versions become widely deployed across major compilers, and used by developers?

I think this is a bit exaggerated. I mostly find it not difficult to avoid UB in C. There are mainly five areas where you can have problems: type safety issues, signed integer overflow, out-of-bounds accesses, use-after-free, and race conditions. Type safety is generally not a problem if you avoid unsafe casts (and casts are easy to screen for just like "unsafe"), signed overflow one can protect against via sanitizers or one can rule it out statically, and out-of-bounds accesses you can avoid by using safe buffer and string abstractions and never doing open-coded pointer arithmetic.

Use-after-free and race conditions are the areas where Rust has a clear advantage. Here one needs to have a clear strategy and enforce it manually (or using tools, but we lack good open-source tools for this). Valgrind and similar tools also help.

Almost but not quite. You are promised that safe Rust doesn't have Undefined Behaviour, but that's cultural, not technological. The technology is just enabling Rust's culture to deliver what they promised, but it would be very easy to purposefully (indeed there are known bugs where it does happen, look for "Rust soundness bug" if you want examples) inject UB which happens in your safe Rust.

The extent to which this is about culture should not be underestimated, to me that's the most hilarious part of Bjarne Stroustrup's big rant on memory safety a few years ago. The C word appears exactly once in his slides, in a quote from somebody else about what needs fixing. But Bjarne never addresses this once, even though it's the actual problem.

Sure Rust is better on it, my point is that it is there, despite that community making it a Big Freakin' Deal to have all the memory safe they could design into the compiler and language.

If even they had to add escape hatches despite the presences of powerful language primitives like types, traits, borrow-checking, maybe the people charged with making it all work with 80s compiler technology weren't the literal Antichrist for also having UB as Rust does.

For what it's worth, C and C++ are much different in terms of hazard, so when you bucket them together it makes me wonder how familiar you are with the actual risk of UB in practice.

Nowadays it generally stems from doing weird things.... but no one is making you do weird things, any more than people are making you use Rust's unsafe keyword.

Whatever happens for the other UB remains bounded memory safely in Fil-C. (according to a definition of memory safety that excludes protection of subobject bounds, but Rust also redefines memory safety to what the Rust compiler can do, e.g. excludes memory leaks).

Do you have a concrete example of C which will "still explode" ?

  #include <stdio.h>
  #include <stdlib.h>

  int shift(int x, int n) { return x << n; }

  int main(int argc, char **argv) {
      printf("%d\n", shift(1, 32));   /* n == width: UB */
      return 0;
  }

    static void loop(void) {
        int s = shift(1, 32);
        int n = 0;
        for (int i = 0; i < s + 3; i++)
            n++;
        printf("[loop] iterations=%d (s+3=%d)\n", n, s + 3);
    }
    
    static void sw(void) {
        switch (shift(1, 32)) {
        case 0:  puts("[switch] case 0"); break;
        case 1:  puts("[switch] case 1"); break;
        default: puts("[switch] default"); break;
        }
    }
    
    int main(int argc, char **argv) {
        loop();
        sw();
        return 0;
    }

    #include <stdio.h>
    #include <stdlib.h>
    
    __attribute__((noinline)) static void poke(int *p, int k)
    {
        int n = 32 + (k & 15);          /* always >= 32: shifting an int by >= 32 is UB */
        p[(1 << n) * 20] = 0x41414141;  /* on x86 the CPU computes index 40, out of bounds */
    }

    int main(int argc, char **argv)
    {
        int *p = calloc(16, sizeof(int));
        poke(p, argc);
        puts("after poke");
        return 0;
    }

debugger;