[issue14656] Add a macro for unreachable code

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue14656] Add a macro for unreachable code

Zackery Spytz added the comment: The Py_UNREACHABLE() macro was implemented in bpo-31338, so this issue can be closed. -- nosy: +ZackerySpytz ___ Python tracker ___

[issue14656] Add a macro for unreachable code

Martin v. Löwis mar...@v.loewis.de added the comment: Sorry, I missed the patch. I still fail to see the problem that this solves: what compiler produces control reaches end of non-void function without return for the current code? ISTM that your patch has the potential of *introducing* such

[issue14656] Add a macro for unreachable code

STINNER Victor victor.stin...@gmail.com added the comment: I think you misuse __builtin_unreachable(): the code *is* reachable, it is just very unlikely. I really prefer to return something looking valid and continue the execution of the program, instead of calling the evil Py_FatalError() in

[issue14656] Add a macro for unreachable code

Antoine Pitrou pit...@free.fr added the comment: I really prefer to return something looking valid and continue the execution of the program How would that be better? Should Python become more like PHP? -- nosy: +pitrou ___ Python tracker

[issue14656] Add a macro for unreachable code

STINNER Victor victor.stin...@gmail.com added the comment: Oh, I read again the patch. There are two different cases: * The code is really unreachable. Ex: the loop of lookdict() does never stop, return is used in the loop. Py_UNREACHABLE can be used in this case *to avoid a compiler

[issue14656] Add a macro for unreachable code

Antoine Pitrou pit...@free.fr added the comment: I like the current solution: assert(0) + return a almost valid value, but Antoine and Benjamin don't like the almost valid value (and so prefer a fatal error?). We may issue a warning instead of a fatal error (e.g. write a message into

[issue14656] Add a macro for unreachable code

Georg Brandl ge...@python.org added the comment: If there's a bug, either an exception should be raised, or a fatal error. We should discourage warnings on stderr (the PHP approach). Agreed. That said, I'm with Martin in that don't see how the patch in this issue helps. -- nosy:

[issue14656] Add a macro for unreachable code

Martin v. Löwis mar...@v.loewis.de added the comment: Py_UNREACHABLE can be used in this case *to avoid a compiler warning*. What is the specific warning that you want to avoid, and what specific compiler version produces it currently on what specific code? It's not control reaches end of

[issue14656] Add a macro for unreachable code

Benjamin Peterson benja...@python.org added the comment: It does not avoid any warning because we have the assert(0); return X pattern. I was just attempting to provide a standard way of marking unreachable code. -- ___ Python tracker

[issue14656] Add a macro for unreachable code

Martin v. Löwis mar...@v.loewis.de added the comment: I was just attempting to provide a standard way of marking unreachable code. I'm -1 for the proposed patch (and probably -0 on the general idea). I think the patch has the potential *introducing* new warnings, as compilers might warn that

[issue14656] Add a macro for unreachable code

Martin v. Löwis mar...@v.loewis.de added the comment: Please, go ahead, explain :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14656 ___ ___

[issue14656] Add a macro for unreachable code

Benjamin Peterson benja...@python.org added the comment: Did you see the sample patch I posted? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14656 ___

[issue14656] Add a macro for unreachable code

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14656 ___ ___

[issue14656] Add a macro for unreachable code

Benjamin Peterson benja...@python.org added the comment: Let me explain what I meant with code. -- keywords: +patch Added file: http://bugs.python.org/file25346/unreachable.patch ___ Python tracker rep...@bugs.python.org

[issue14656] Add a macro for unreachable code

New submission from Benjamin Peterson benja...@python.org: It would be nice to have a macro Py_UNREACHABLE to keep compiler warnings away in unreachable code. This is can call __builtin_unreachable on gcc and abort elsewhere. -- components: Interpreter Core keywords: easy messages:

[issue14656] Add a macro for unreachable code

Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14656 ___ ___ Python-bugs-list

[issue14656] Add a macro for unreachable code

Martin v. Löwis mar...@v.loewis.de added the comment: What's the specific warning that you want to eliminate? -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14656 ___

[issue14656] Add a macro for unreachable code

Benjamin Peterson benja...@python.org added the comment: 2012/4/23 Martin v. Löwis rep...@bugs.python.org: Martin v. Löwis mar...@v.loewis.de added the comment: What's the specific warning that you want to eliminate? control reaches end of non-void function without return Basically,

[issue14656] Add a macro for unreachable code

Martin v. Löwis mar...@v.loewis.de added the comment: What's the specific warning that you want to eliminate? control reaches end of non-void function without return Basically, whenever you see assert(0) today. Sorry, what I meant is: what specific line (in what specific source file) is

[issue14656] Add a macro for unreachable code

Benjamin Peterson benja...@python.org added the comment: 2012/4/23 Martin v. Löwis rep...@bugs.python.org: Martin v. Löwis mar...@v.loewis.de added the comment: What's the specific warning that you want to eliminate? control reaches end of non-void function without return Basically,

[issue14656] Add a macro for unreachable code

Martin v. Löwis mar...@v.loewis.de added the comment: Right, we currently avoid this problem by writing assert(0) for example in lookdict_split in dictobject.c. What I'm saying is that instead writing assert(0), we could use Py_UNREACHABLE. I don't understand. The assert(0) is not there to