Author eric.smith
Recipients eric.smith
Date 2022-01-06.14:52:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1641480745.66.0.334311136803.issue46280@roundup.psfhosted.org>
In-reply-to
Content
Thank you for posting this.

Some of these look like false positives.

For example:
#263
Parser/string_parser.c:670: error: Uninitialized Value
  The value read from parenstack[_] was never initialized.
  668.             }
  669.             nested_depth--;
  670.             int opening = (unsigned char)parenstack[nested_depth];
                   ^
  671.             if (!((opening == '(' && ch == ')') ||
  672.                   (opening == '[' && ch == ']') ||

I don't see how this could be an uninitialized read, although I'm willing to be wrong.

If your tool can produce patches to fix reported problems, I suggest that you create PRs for specific issues, so they can be reviewed individually. There's no way we'd review a single patch for all 673 issues that were identified.

Also, looking at the first one:
#0
Objects/clinic/bytearrayobject.c.h:50: error: Dead Store
  The value written to &noptargs (type long) is never used.
  48.             goto exit;
  49.         }
  50.         if (!--noptargs) {
                   ^
  51.             goto skip_optional_pos;
  52.         }

We've discussed this before. The consensus last time was to leave code like this in place, in case other code was added after this that refers to the same pointer. Our assumption is that compilers will remove the unneeded store. Is it possible to remove Dead Stores from the output, and/or produce a separate output with just Dead Stores? I don't see how a Dead Store can be a vulnerability.
History
Date User Action Args
2022-01-06 14:52:25eric.smithsetrecipients: + eric.smith
2022-01-06 14:52:25eric.smithsetmessageid: <1641480745.66.0.334311136803.issue46280@roundup.psfhosted.org>
2022-01-06 14:52:25eric.smithlinkissue46280 messages
2022-01-06 14:52:25eric.smithcreate