This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ammar2, gregory.p.smith, malin, serhiy.storchaka, sir-sigurd, vstinner, zach.ware
Date 2019-09-19.10:00:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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:57vstinnersetrecipients: + vstinner, gregory.p.smith, zach.ware, serhiy.storchaka, malin, ammar2, sir-sigurd
2019-09-19 10:00:57vstinnersetmessageid: <>
2019-09-19 10:00:57vstinnerlinkissue38205 messages
2019-09-19 10:00:57vstinnercreate