[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 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 a return is lacki

[issue14656] Add a macro for unreachable code

Benjamin Peterson 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 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 non-void function

[issue14656] Add a macro for unreachable code

Georg Brandl 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: +georg.brandl ___

[issue14656] Add a macro for unreachable code

Antoine Pitrou 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 stderr with f

[issue14656] Add a macro for unreachable code

STINNER Victor 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 warning*. __builtin_unreachable(

[issue14656] Add a macro for unreachable code

Antoine Pitrou 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 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 release mode which stops i

[issue14656] Add a macro for unreachable code

Martin v. Löwis 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 a warning on some

[issue14656] Add a macro for unreachable code

Benjamin Peterson added the comment: Did you see the sample patch I posted? -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue14656] Add a macro for unreachable code

Martin v. Löwis added the comment: Please, go ahead, explain :-) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue14656] Add a macro for unreachable code

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue14656] Add a macro for unreachable code

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

[issue14656] Add a macro for unreachable code

Martin v. Löwis 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 silence any c

[issue14656] Add a macro for unreachable code

Benjamin Peterson added the comment: 2012/4/23 Martin v. Löwis : > > Martin v. Löwis 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, w

[issue14656] Add a macro for unreachable code

Martin v. Löwis 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 that warnin

[issue14656] Add a macro for unreachable code

Benjamin Peterson added the comment: 2012/4/23 Martin v. Löwis : > > Martin v. Löwis 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. -- ___

[issue14656] Add a macro for unreachable code

Martin v. Löwis added the comment: What's the specific warning that you want to eliminate? -- nosy: +loewis ___ Python tracker ___ __

[issue14656] Add a macro for unreachable code

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue14656] Add a macro for unreachable code

New submission from Benjamin Peterson : 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: 159088 nosy: benjamin.