> Fil-C or similar runtime handling so that any time its behaviour would become undefined the program exits instead

It’s worth being clear here that this is not what Fil-C does, it still has UB, and can still explode in many of the same ways as C and all (after all, it’s a clang fork). Fil-C takes one particular class of allocation related bugs and UB off the table, but leaves many of them behind.

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

I'm not so sure you can make such a strong statement about what happens when UB is invoked. The presence of UB allows the compiler to make all kinds of weird assumptions, and it seems very unlikely that there exists no series of allowable transforms that results in a pointer capabilities check being elided or similar.

Presumably Martin intends the usual caveat that this is subject to bugs. So, "there might be a bug in the compiler" isn't interesting. There are bugs in LLVM, bugs in Rust's trait resolution, bugs in Javascript implementations, obviously code has bugs and that's generally not very interesting - we can fix bugs.

Are you claiming that there must be such transforms or only that it is likely that bugs exist which isn't interesting.

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

  #include 
  #include 

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

This program exhibits UB in Fil-C, and you can see that the optimizer does different things at -O0 (outputs 1) and -O1/-O2/-O3 (outputs 0). Since this creates poison, which Fil-C doesn't remove, you can use it to construct all kinds of weird things.

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

In Fil-C -O0, this gives 4 iterations of the loop and executes sw(). At any higher optimization level, it turns loop() into an infinite loop and drops sw() from the binary entirely.

Neither of those sound like Undefined Behaviour to me, they're maybe unspecified but they don't sound undefined at all - are you confusing Undefined Behaviour with "I wanted it to do something else" ?

You said "explode" earlier and so I was expecting something a bit more dramatic than "Unsurprisingly Fil-C has unspecified results for some expressions".