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 barry, pitrou, serhiy.storchaka, vstinner
Date 2020-03-09.08:40:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Antoine: "I agree with Serhiy.  If you hit a rare situation that you don't want to handle, use Py_FatalError(), not Py_UNREACHABLE()."

Py_UNREACHABLE() documentation still says "Use this when you have a code path that you do not expect to be reached." and "Use this in places where you might be tempted to put an assert(0) or abort() call."

Can we clarify when Py_UNREACHABLE() must *not* be used?

I understand that there are two cases:

* Code path very unlikely to reach, but can be reached in some exceptional case. If it's reached, Python must report an error. Example: _PyTime_GetSystemClock().
* Code path which cannot be technically reached: compiler complains but it's a compiler/linter false alarm. Example: lookdict_index().

I propose to rephrase the Py_UNREACHABLE() macro documentation:

"Use this when you have a code path that cannot be reached by design. For example, in the default: clause in a switch statement for which all possible values are covered in case statements. Use this in places where you might be tempted to put an assert(0) or abort() call.

Don't use this macro for very unlikely code path if it can be reached under exceptional case. For example, under low memory condition or if a system call returns a value out of the expected range."

I suggest to update the doc as part of PR 16329.
Date User Action Args
2020-03-09 08:40:03vstinnersetrecipients: + vstinner, barry, pitrou, serhiy.storchaka
2020-03-09 08:40:03vstinnersetmessageid: <>
2020-03-09 08:40:03vstinnerlinkissue38249 messages
2020-03-09 08:40:02vstinnercreate