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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
