On Fri, Nov 15, 2024 at 06:53:59AM +0100, Siteshwar Vashisht wrote:
> - The issue of false positives is one of the most important, but hard
> to solve. I started a discussion[2] on GitHub, but we do not have a
> good answer to it yet. If you have ideas, please share on GitHub.

Hi,

This was already partially discussed in the other part of the thread
with František, but without a clear conclusion on the reported issues.
I looked into the reports for systemd, and generally they are all
false positives, and actually quite immediately obvious false positives.

The very first report is:
  #   70|               eval "arr=( $line )"
  #   71|->             case "${arr[0]}" in
  /usr/lib/rpm/sysusers.generate-pre.sh:71:9: warning[SC2154]: arr is 
referenced but not assigned.

Then there are reports of various leaks, but it's pretty clear
that __attribute__(cleanup) is not being understood.

A bit later is:
  #  273|->         return RET_NERRNO(open(path, O_CLOEXEC|O_PATH));
  systemd-257_rc1-build/systemd-257-rc1/src/basic/build-path.c:273:16: 
warning[-Wanalyzer-fd-leak]: leak of file descriptor ‘open(path, 2621440)’

i.e. the value that is returned via 'return', not leaked.

I also looked at the reports for util-linux. They first few are fairly
obvious false positives too:

  util-linux-2.40.2-build/util-linux-2.40.2/disk-utils/fdformat.c:127:49: 
warning[-Wanalyzer-possible-null-dereference]: dereference of possibly-NULL 
‘xmalloc((long unsigned int)track_size) + (sizetype)count’

  util-linux-2.40.2-build/util-linux-2.40.2/disk-utils/mkfs.cramfs.c:304:9: 
warning[-Wanalyzer-possible-null-argument]: use of possibly-NULL ‘xmalloc(len + 
257)’ where non-null expected

(xmalloc, xstrdup are obviously non-failing wrappers for malloc and strdup)

#  992|->               } else if (*s == '!') {
util-linux-2.40.2-build/util-linux-2.40.2/disk-utils/fsck.c:992:28: 
warning[-Wanalyzer-malloc-leak]: leak of ‘xstrdup(fs_type)’

This one is strange, because it reports a comparison operation as
doing something.

It seems pretty clear that the signal-to-noise ratio is extremely low.
I don't think it's useful to tell people to look into those reports
until this ratio improves quite a bit.

> [2] https://github.com/openscanhub/openscanhub/issues/290

Zbyszek
-- 
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to