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.
> 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.
Remember we're not discussing our personal approaches, we're discussing what the linked post describes. It does mention UBSAN down one level of link but does not point out the pitfalls, which is the thing I'm taking issue with. I agree your approach is reasonable. It is, however, not what people reading the linked article would arrive at.
> I think it's nice because it lets you keep the same definition for both debug and release.
I would never consider turning blanket-all assert()s into assumptions for a release build. Every single assert would become a source of potential UB. This is why we have separate assert() and assume() in our codebase.
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.