On Tue, Nov 19, 2024 at 6:08 PM David Malcolm wrote:
>
> On Tue, 2024-11-19 at 17:25 +0100, František Šumšal wrote:
> > On 11/19/24 10:22, František Šumšal wrote:
> > > On 11/19/24 09:07, Kamil Dudka wrote:
> > > > On Monday, November 18, 2024 6:57:03 PM GMT+1 František Šumšal
> > > > wrote:
> > >
Just to add some positive news after my previous (and somewhat negative emails)
- I rebuilt polkit with GCC analyzer and LTO which yielded four warnings and
all of them were real issues (well, the last one was a potential one, but I
understand why GCC analyzer reported it). So it seems to work
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 alread
On 11/19/24 18:07, David Malcolm wrote:
On Tue, 2024-11-19 at 17:25 +0100, František Šumšal wrote:
On 11/19/24 10:22, František Šumšal wrote:
On 11/19/24 09:07, Kamil Dudka wrote:
On Monday, November 18, 2024 6:57:03 PM GMT+1 František Šumšal
wrote:
Right after I sent this I got a response
On Tue, 2024-11-19 at 17:25 +0100, František Šumšal wrote:
> On 11/19/24 10:22, František Šumšal wrote:
> > On 11/19/24 09:07, Kamil Dudka wrote:
> > > On Monday, November 18, 2024 6:57:03 PM GMT+1 František Šumšal
> > > wrote:
> > > > Right after I sent this I got a response [0] to the gcc bug and
On 11/19/24 10:22, František Šumšal wrote:
On 11/19/24 09:07, Kamil Dudka wrote:
On Monday, November 18, 2024 6:57:03 PM GMT+1 František Šumšal wrote:
Right after I sent this I got a response [0] to the gcc bug and turns out that
the culprit is disabled LTO. And indeed, if I build systemd with
On 11/19/24 09:07, Kamil Dudka wrote:
On Monday, November 18, 2024 6:57:03 PM GMT+1 František Šumšal wrote:
Right after I sent this I got a response [0] to the gcc bug and turns out that
the culprit is disabled LTO. And indeed, if I build systemd with `-fanalyzer
-flto=auto`, (almost) all repo
On Monday, November 18, 2024 6:57:03 PM GMT+1 František Šumšal wrote:
> Right after I sent this I got a response [0] to the gcc bug and turns out
> that the culprit is disabled LTO. And indeed, if I build systemd with
> `-fanalyzer -flto=auto`, (almost) all reports disappear:
>
> With just -fana
Right after I sent this I got a response [0] to the gcc bug and turns out that
the culprit is disabled LTO. And indeed, if I build systemd with `-fanalyzer
-flto=auto`, (almost) all reports disappear:
With just -fanalyzer (meson setup build -Dc_args="-fanalyzer"):
$ grep warning: log-fanalyzer.
Hey,
Thank you for doing this!
I started taking apart systemd findings and reported a first issue against gcc
[0], so we can hopefully squash the false positives from the results (at least
the ones repored by gcc's -fanalyzer) and make them more useful.
One thing that comes to mind (especiall
On Fri, Nov 15, 2024 at 06:36:14AM +0100, Siteshwar Vashisht wrote:
> On Thu, Nov 14, 2024 at 10:47 PM Kevin Fenzi wrote:
> >
> > What does it mean when the table lists the package version as 'el8'?
>
> I was trying to reuse some scripts that are used to generate reports
> for RHEL and they did n
That went on the wrong thread, sorry, lol.
--
___
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-conduc
Just out of curiosity, in the fclose(..) case, my original thought was
that the exit(1) call would close the file descriptor. Is it still
necessary because of a possibility of some atexit hanging the process
and holding the fd longer than expected, hence the possible resource
leak? Or is it bec
A few were actually good, and they were fixed right away upstream.
Thanks again for the report!
Carlos R.F.
On 11/14/24 10:14 PM, Carlos Rodriguez-Fernandez wrote:
Thanks for sharing the report. I looked into the libcap ones and they
all appear to be false positives, but I can see why gcc stru
On Thu, Nov 14, 2024 at 10:23 PM Richard W.M. Jones wrote:
>
> On Thu, Nov 14, 2024 at 08:47:36AM +0100, Siteshwar Vashisht wrote:
> > Hello,
> >
> > I am writing this message to get feedback from the community on new
> > findings by static analyzers in Critical Path Packages that have
> > changed
On Thu, Nov 14, 2024 at 10:47 PM Kevin Fenzi wrote:
>
> What does it mean when the table lists the package version as 'el8'?
I was trying to reuse some scripts that are used to generate reports
for RHEL and they did not work as expected. I have fixed it now.
Please take a look at the report again
Thanks for sharing the report. I looked into the libcap ones and they
all appear to be false positives, but I can see why gcc struggles to
figure it out. I forwarded them to the upstream developer for confirmation.
Thank you,
Carlos R.F.
On 11/14/24 12:47 AM, Siteshwar Vashisht wrote:
Hello,
What does it mean when the table lists the package version as 'el8'?
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora C
On Thu, Nov 14, 2024 at 08:47:36AM +0100, Siteshwar Vashisht wrote:
> Hello,
>
> I am writing this message to get feedback from the community on new
> findings by static analyzers in Critical Path Packages that have
> changed in Fedora 42.
>
> TLDR: This report[1] contains 37330 findings. Please
19 matches
Mail list logo