Guido van Rossum <gu...@python.org> added the comment:
Good catch! Are all the coverity complaints about this kind of code? if (_res == NULL && PyErr_Occurred()) { ... } (Mostly for Pablo and Lysandros:) This comes from emit_action(). It is preceded by a line of the form _res = <action>; Most of the time the action is a function call, so this looks like _res = <some function call which can really fail>; But occasionally the action is just pulling a named item from the alternative that was just recognized, and those variables are generally known to be non-NULL (because otherwise the alternative would fail). There seem to be a whole bunch of actions of the form { <variable> }. A typical example: else_block[asdl_seq*]: 'else' ':' b=block { b } We could probably recognize actions that take the form of a single variable and suppress the error check for the result. However, there's a wrinkle. Sometimes a variable may legitimately be NULL when an alternative is recognized! This could occur if the name refers to an optional item. I even found an example: | 'class' a=NAME b=['(' z=[arguments] ')' { z }] ':' c=block { Look closely at the part starting with b=: b=['(' z=[arguments] ')' { z }] In the sub-rule we see z=[arguments] and the action is { z } so it is possible that we reach the `_res = z` part while z is NULL. In my copy of parser.c (current master) this is in _tmp_69_rule(). IMO this makes it difficult to omit the error check in exactly the right situations. Moreover, isn't it the job of the compiler to optimize code so we don't have to? The code generator is complex enough as it is; I would prefer not to have to complexificate it just so Coverity won't complain about unreachable code (no matter how right it is!). I know nothing about Coverity any more. Is it possible to exempt this giant generated file from warnings about unreachable code? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41059> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com