On Thu Nov 17 23:31:34 2022 +0000, Zebediah Figura wrote:
To me, the difference is: invariants which might be violated by accident deserve to be written in the code to remind the reader of the invariant, and they deserve a warning to be printed if they're violated. By contrast, invariants which can only be violated via memory corruption should, in theory, not even be written in the code—simply because memory corruption can happen anywhere and it's a waste of time to write those assertions. In my opinion the only reason we have vkd3d_unreachable() in things like switch default cases is that the compiler would warn otherwise. I did forget that vkd3d_unreachable() actually effectively includes an assert, though; I thought it was always equivalent to __builtin_unreachable(). Maybe both types should be vkd3d_unreachable(), though, as it is. I.e. if you're a user who trusts the programmer to not violate their own invariants, and you want the most efficient code...
Yeah, in my intention `vkd3d_unreachable()` is equivalent to `assert(0)`, so it aborts with an error message without `NDEBUG` and it does nothing with `NDEBUG`, but with the difference that it lets the compiler knows (either via `__builtin_unreachable()` or via `__attribute__((noreturn))` that that piece of code is not meant to be reached (mostly so that the compiler spares us with its overzealous warnings without us sticking in dummy `return 0` statements; in theory there is also a performance gain, but I doubt that's ever going to be visible).
I say that I don't see a real difference between violating an invariant by accident or by memory corruption because in practice I don't know how to differentiate between the two in advance.