Message352783
> 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. |
|
Date |
User |
Action |
Args |
2019-09-19 10:00:57 | vstinner | set | recipients:
+ vstinner, gregory.p.smith, zach.ware, serhiy.storchaka, malin, ammar2, sir-sigurd |
2019-09-19 10:00:57 | vstinner | set | messageid: <1568887257.51.0.23545499431.issue38205@roundup.psfhosted.org> |
2019-09-19 10:00:57 | vstinner | link | issue38205 messages |
2019-09-19 10:00:57 | vstinner | create | |
|