Not very. It really just means that "there is a sanitized mode for building", which already exists in many C and C++ compilers (for language UB) and standard libraries (for library UB).

I think Zig's ReleaseSafe mode is intended to be suitable for production, which IIUC isn't really the case with ASan, UBSan, and friends. Those have some performance problems and also some attack surface problems.

OK, but is "safe" in ReleaseSafe any kind of guarantee, or is it just safer than ReleaseFast?

I can enable lightweight assertions in libstdc++ and libc++ and it makes C++ safer, but not in any way "safe". There are some flags that can be enabled to trap on some language UB too, without bringing in the heavy weight sanitizers.

Last time I checked (more than a year ago) there were major open questions about what could be guaranteed. My impression was that you could expect e.g. all array accesses to be bounds checked, but that use-after-free and dangling pointers were still issues, especially if you use the C allocator.

I think of this case as an assert() that both lists are the same length. if they're not, I want to know about that via a crash.

Could you elaborate? What's a safety-checked UB?

Thanks.

So, if I read this correctly, barring the simple cases that Zig can detect at compile-time, this means that whether it's a UB (in the C++ definition of the term) depends on the flags specified by the author of the library and the person who compiles the final binary.

That's definitely much better than C++ UB. Still a bit scary, though.