STINNER Victor <vstin...@python.org> added the comment:
> While it is a macro, it can be made a no-op, or even with compiler-specific > instructions like __builtin_unreachable. My PR 16280 uses _Py_NO_RETURN which uses __attribute__((__noreturn__)) with GCC and clang. I'm not sure how __builtin_unreachable could be used with Py_UNREACHABLE() macro. > While it is a macro, it can be made a no-op I understood that Py_UNREACHABLE() is used on purpose to prevent undefined behavior. For example, if a function accepts an enum, but is called with a value which is not part of the enum: what should happen? Should Python crash? Usually, we try to be nice and return an error. But sometimes, you cannot report an error and so Py_UNREACHABLE() is a good solution. > I prefer to keep it a macro. The compiler does not know that it is never > executed, so it can generate a suboptimal code. I don't see how PR 16280 could have an effect on that. I don't see how the compiler can guess that the code is never executed with the current macro. -- Using a function allows to put a breakpoint on it. In fact, I can easily modify PR 16280 to keep the macro, since I only call Py_FatalError() with a string. The function body is simple. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38205> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
