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

Reply via email to