Jason Orendorff writes: > If the code is truly unreachable, it doesn't matter what we replace it > with. The question is what to do when the impossible occurs. To me, > letting control flow past such a place is just as scary as undefined > behavior.
That depends on the particular code. Often enough, letting control flow past is relatively harmless compared to a crash. > So I think our replacement for MOZ_ASSUME_UNREACHABLE should > crash even in non-debug builds. This suggests MOZ_CRASH. For many of our assertions, letting processing continue when an assertion is not satisfied is just as scary as undefined behaviour. I'm not aware of any reason to treat MOZ_ASSERT_UNREACHABLE differently from MOZ_ASSERT in release builds. Perhaps all asserts should crash by default in release builds. But, as a crash may sometimes be worse than the consequences of a particular assertion failure, perhaps we need to distinguish, ok-to-continue asserts from do-not-continue asserts. Even if we had only the do-not-continue asserts, including array bounds checks, crash in release builds, I don't know the performance or code size costs. I'm guessing we'd still need some dont-want-to-continue-but-too-expensive-to-check variant of assert. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
