STINNER Victor <vstin...@python.org> added the comment:
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." https://docs.python.org/dev/c-api/intro.html#c.Py_UNREACHABLE 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38249> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
