[issue31338] Use abort() for code we never expect to hit

STINNER Victor added the comment: New changeset 54cc0c0789af8ff2396cb19095b7ab269f2bc06c by Victor Stinner in branch 'master': bpo-31338: C API intro: add missing versionadded (#4339) https://github.com/python/cpython/commit/54cc0c0789af8ff2396cb19095b7ab269f2bc06c -- __

[issue31338] Use abort() for code we never expect to hit

Change by STINNER Victor : -- pull_requests: +4293 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue31338] Use abort() for code we never expect to hit

Serhiy Storchaka added the comment: New changeset 8bf288e2c5330148e4bd07d9c2f1ccd05ced5a86 by Serhiy Storchaka (Petr Viktorin) in branch 'master': Docs: Mention that Py_UNREACHABLE was added in 3.7 (#4337) https://github.com/python/cpython/commit/8bf288e2c5330148e4bd07d9c2f1ccd05ced5a86

[issue31338] Use abort() for code we never expect to hit

Change by Petr Viktorin : -- pull_requests: +4291 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue31338] Use abort() for code we never expect to hit

Changes by Barry A. Warsaw : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bu

[issue31338] Use abort() for code we never expect to hit

Barry A. Warsaw added the comment: New changeset b2e5794870eb4728ddfaafc0f79a40299576434f by Barry Warsaw in branch 'master': bpo-31338 (#3374) https://github.com/python/cpython/commit/b2e5794870eb4728ddfaafc0f79a40299576434f -- ___ Python tracker

[issue31338] Use abort() for code we never expect to hit

Changes by Barry A. Warsaw : -- pull_requests: +3385 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue31338] Use abort() for code we never expect to hit

Barry A. Warsaw added the comment: On Sep 5, 2017, at 16:07, STINNER Victor wrote: > > STINNER Victor added the comment: > >> Neither gcc (macOS, Ubuntu), nor clang (Ubuntu) complain. > > Ok, cool. In that case, go ahead. I checked with @steve.dower and I think abort() will work on MSVC too.

[issue31338] Use abort() for code we never expect to hit

STINNER Victor added the comment: > Neither gcc (macOS, Ubuntu), nor clang (Ubuntu) complain. Ok, cool. In that case, go ahead. -- ___ Python tracker ___ ___

[issue31338] Use abort() for code we never expect to hit

Barry A. Warsaw added the comment: So with this diff: modified Include/pymacro.h @@ -95,4 +95,6 @@ #define Py_UNUSED(name) _unused_ ## name #endif +#define Py_UNREACHABLE() abort() + #endif /* Py_PYMACRO_H */ modified Python/compile.c @@ -1350,8 +1350,7 @@ get_const_value(expr_ty e)

[issue31338] Use abort() for code we never expect to hit

STINNER Victor added the comment: +#define Py_UNREACHABLE() abort() Using such macro, I don't think that __builtin_unreachable() is useful. https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Another use for __builtin_unreachable is following a call a function that never returns but that i

[issue31338] Use abort() for code we never expect to hit

STINNER Victor added the comment: > Which compiler needs more than "abort();" in a default statement? gcc and > clang don't. Again, I'm not sure that bpo-28152 is directly related to this issue, but here an example: $ git diff diff --git a/Parser/grammar.c b/Parser/grammar.c index 75fd5b9cde

[issue31338] Use abort() for code we never expect to hit

Stefan Krah added the comment: On Tue, Sep 05, 2017 at 05:10:24PM +, STINNER Victor wrote: > That's a good example of better implementation for Py_UNREACHABLE(). > > The tricky part is to make compiler warnings quiet. For example, you cannot > replace "abort(); return NULL;" with "abort()",

[issue31338] Use abort() for code we never expect to hit

STINNER Victor added the comment: > Or simply you would write: > >Py_UNREACHABLE(); > return NULL; I recall that I had to fix warnings when using clang on: Py_FatalError("..."); return NULL; See bpo-28152. I don't know if it's related to this issue. -- __

[issue31338] Use abort() for code we never expect to hit

Antoine Pitrou added the comment: Le 05/09/2017 à 19:10, STINNER Victor a écrit : > > Maybe the default implementation of the macro should be: > > #define Py_UNREACHABLE(stmt) abort(); stmt Or simply you would write: Py_UNREACHABLE(); return NULL; --

[issue31338] Use abort() for code we never expect to hit

STINNER Victor added the comment: > As suggested in http://bugs.python.org/issue31337#msg301229 it would be > better to use > abort() /* NOT REACHED */ Please don't use abort(), but add a new Py_UNREACHABLE() macro to allow to use a different code depending on the compiler/platform and compile

[issue31338] Use abort() for code we never expect to hit

Serhiy Storchaka added the comment: Can we use compiler-specific code like GCC's __builtin_unreachable()? This would help the optimizer. -- ___ Python tracker ___ __

[issue31338] Use abort() for code we never expect to hit

Stefan Krah added the comment: And Solaris lint recognizes it: https://docs.oracle.com/cd/E60778_01/pdf/E60745.pdf Actually it could be that the convention comes right from K&R, but I can't find my copy right now. -- ___ Python tracker

[issue31338] Use abort() for code we never expect to hit

Stefan Krah added the comment: > Is /* NOT REACHED */ a common convention? I think it's often used in BSD, I first saw it in OpenBSD. A macro is fine of course. -- ___ Python tracker

[issue31338] Use abort() for code we never expect to hit

Changes by Barry A. Warsaw : -- pull_requests: +3358 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue31338] Use abort() for code we never expect to hit

Barry A. Warsaw added the comment: > > Can we have a Py_UNREACHABLE() macro for that, then? > First, it makes the intent extra clear without needing any additional > comment. Second, it can be defined however we need in order to get along > with the various tools around. +1 --

[issue31338] Use abort() for code we never expect to hit

Antoine Pitrou added the comment: Can we have a Py_UNREACHABLE() macro for that, then? First, it makes the intent extra clear without needing any additional comment. Second, it can be defined however we need in order to get along with the various tools around. -- nosy: +pitrou __

[issue31338] Use abort() for code we never expect to hit

Barry A. Warsaw added the comment: @skrah - quick question. Is /* NOT REACHED */ a common convention? Do any compilers or IDEs recognize it? Is it documented anywhere? I like the idea of adding that comment on the abort(), but I'm trying to find some prior art or references for that.

[issue31338] Use abort() for code we never expect to hit

Barry A. Warsaw added the comment: I'm thinking there are two aspects to this. One would involve updates to PEP 7 to include a section on "Unreachable code". The other would be a PR that updates the current C code to the PEP 7 standard. I'll work on a PEP update as a separate PR, then we can

[issue31338] Use abort() for code we never expect to hit

Serhiy Storchaka added the comment: The fact that assert() is compiled out in release build looks as an advantage to me. This allows the compiler to generate smaller code. I'm in favor of using assert(!"message"), but this form is rarely used in CPython sources. I think it would be nice to ask

[issue31338] Use abort() for code we never expect to hit

Stefan Krah added the comment: Regarding lint warnings, I may have confused abort() with exit(). Lintian has the shlib-calls-exit tag, somehow I thought there was a similar one for abort(), but I can't find it now. -- ___ Python tracker

[issue31338] Use abort() for code we never expect to hit

New submission from Barry A. Warsaw: Over in bpo-31337 the observation was made that we often use the following pattern in situations we never expect to hit: assert(0); return NULL; but this isn't strictly optimal. First, the asserts can be compiled away. Second, it's possible that our assu