Guido van Rossum <[email protected]> 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 <[email protected]>
<https://bugs.python.org/issue41059>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com