5 ms·
I know it, but if you have a bug that reach the Unreachable path the compiler can't tell you anything. that is why I use assert(0) in debug builds.
by pmarin 3y ago
I know it, but if you have a bug that reach the Unreachable path the compiler can't tell you anything. that is why I use assert(0) in debug builds.
- peterfirefly 3y agoAnd you can effectively do both: #ifdef NDEBUG # define UNREACHABLE() unreachable() #else # define UNREACHABLE() assert(0) #endif That's what I have been doing for years, except with __builtin_unreachable()... and __assume(0) if I bothered to make it work under MSVC.
- pmarin 3y agoAnd why this is not the default behaviur? I am pretty sure many users are going to think it is correctness check an not an optimization attribute.
- peterfirefly 3y agoBecause C is a "do exactly as I say" language.
- dzaima 3y agoI'd rather not have a basic feature be put behind needing to define an arbitrary NDEBUG; having to define your debugging setup around NDEBUG would not fit some things - e.g. in my case I'd end up having to always define NDEBUG, and continue with my own wrapper around things. (with <assert.h> you have the option of writing your own thing if you don't like its NDEBUG check, which is what I do; with unreachable(), if you literally cannot get its functionality other than NDEBUG, you're stuck with NDEBUG).
- dzaima 3y agoAnd you can easily do a macro check and define a custom thing that's either assert(0) or unreachable() depending on the build type. But you still need unreachable() to exist to do that. (and under -fsanitize=undefined you get an error for unreachable() too)
- astrange 3y agoIt can, just turn on UBSan.
- deleted 3y ago[deleted]