I've found it to have quite poor defaults for its analysis (things like suggesting "use annex k strcpy_s instead of strcpy").
fanalyzer is still by far the easiest to configure.
Why would I ever have a debug build without sanitizers? Nothing stops you from removing the asserts in this case, anyway. I don't see what the problem is with using __builtin_unreachable in this context.
I think you didn't understand - what I was implying is to leave the asserts in for a release build, because they (theoretically) never happen, because they are free optimization hints.
So effectively, instead of a macro, your asserts become controlled by the presence of sanitizers.
I think it's nice because it lets you keep the same definition for both debug and release.
Asserts are to make your code more sensitive to defects, for example, checking function invariants. Ideally the library has more, not less, since they show care and thought has gone in. They should never be used to handle errors.
Another feature of asserts is that `-DNDEBUG` disables them.
Probably it should be stated explicitly, but this is implied if you add `-fsanitize=undefined`, where you will get a diagnostic if the unreachable code is reached. With `-fsanitize-trap=undefined`, you get a trap instruction there, the compiler won't delete anything. In a "release build" without sanitizers, this also serves as an optimization hint. It's a sensible idea, this snarky comment is unwarranted.
Also, code after __builtin_trap() is treated as dead.