I'm sorry to jump out on that sort of issue again, because it was partially treated in issues such as #4830.

To comment @andrewrk in the previous issue :

Figuring out why such checks are always enabled in zig cc is left as an exercise for the reader.

I can speak to this. zig cc is intentionally an interface to the zig compiler, a bit higher level than using clang directly. With no optimization flags specified, zig cc infers debug mode. As you know from writing Zig code, debug mode has safety checks to prevent undefined behavior at runtime. This applies for C code as well, taking advantage of clang's UBSAN. The fact that debug mode is "default" is entirely intentional. I expect this to identify many bugs in existing codebases as people use zig cc out of convenience or curiosity and their code gets vetted by UBSAN for the first time.

The part about detecting issues in other code is 100% true. I've been using zig as a C compiler for some personal project and I've been detected already two UB in major code (nuklear and stb_printf).
But while this is incredibly useful at detecting faulty code, I think it could be better at giving out info about what's wrong. In the two cases, my workflow had been :

1. See that my code crashes in Debug build.
2. Launch gdb, trying to understand what went wrong, check out my user code several times.
3. Finally understand that the SIGILL triggered might be linked to clang UBSAN.
4. Recompile the whole project without build.zig using only clang -fsanitize=undefined, without the trap flag
5. Now run again, and see the exact error that clang outputs (even if it keeps the program running with UB). Now have a precise clue about what part of the C spec that has been violated by the library code that I'm using.

Just a plain crash without info is pretty harsh. I'm 100% in favor of not having UB code running, and I'm 100% in favor of detecting more UB code in the future, but I think right now we lack the tool to properly investigate the exact issue encountered by the UB sanitizer.

Maybe there's a flag that I'm missing. From clang doc, I tried -fno-sanitize-recover=undefined in my compile flags, but it did not worked.