Antonin Décimo

> I am nervous about `unreachable`. If I understand correctly, before we used `CAMLassert(0)`, which means "in debug mode have a clean error, otherwise do nothing", and then we would...

I'm a bit disappointed by my last endeavor. GCC, clang, and MSCV have oh-so-subtly different behaviors regarding unreachable warnings and switch exhaustiveness check. This makes the code somewhat more verbose...

Rebase is done. Maybe @gasche still has comments?

> My comment remains that if some of those `unreachable()` are in fact reachable in case of programming bugs by the user, then I would prefer something that fails cleanly...

Thank you for the pointers, that was really helpful. I've changed the definition of `CAMLunreachable` to trap if the compiler supports it, or use `CAMLassert(0)` if not (the current state).

In the latest revision, I've introduced two new macros: `CAMLtrap()`, and `unreachable()` (for before C23). We may use `CAMLtrap()` to quickly halt the program execution if it reaches an invalid...

The PR doesn't change the behavior of the interpreter if it encounters an invalid opcode. I think that's better reexamined in another PR or issue.

I've rebased this PR and added a fix for an incorrect assertion I've found using cppcheck in the meantime. Let me know if there's more you'd like to see or...

> I had yet yet yet another look at this PR. Thanks a lot for your time and energy! > The changes are mostly in the `default` branches of switches...

This makes sense. Thanks for your comments. Now `unreachable()` traps the program. I did not think the compiler would eliminate the branch, and I should have tested this.