On Friday, May 15, 2020 5:11:40 AM CEST Paul Eggert wrote:
> On 5/14/20 1:34 AM, Kamil Dudka wrote:
> > Now I see that we can just
> > build coreutils with -Dlint even for binary RPMs without any drawbacks.
>
> Good, and that also means you don't need the coreutils-8.32-if-lint.patch
> that you
On 5/14/20 1:34 AM, Kamil Dudka wrote:
> Now I see that we can just
> build coreutils with -Dlint even for binary RPMs without any drawbacks.
Good, and that also means you don't need the coreutils-8.32-if-lint.patch that
you mentioned earlier. One less thing to maintain.
> Such a program can
On Thursday, May 14, 2020 6:23:19 AM CEST Paul Eggert wrote:
> I doubt whether anybody will care about that "waste"; it's just a few
> instructions.
Good point. I did not look at what merge_tree_destroy() and queue_destroy()
really do and thought that their complexity was O(n). Now I see that
On 5/13/20 5:49 AM, Kamil Dudka wrote:
> http://git.savannah.gnu.org/cgit/acl.git/commit?id=33f01b5d
Yes, I have no doubt that valgrind etc. helps find problems in both coreutils
and elsewhere. But that's not the issue here.
>> Why isn't it less work to build and analyze with '-Dlint'?
>
>
On Wed, May 13, 2020 at 8:49 AM Kamil Dudka wrote:
> On Tuesday, May 12, 2020 11:58:49 PM CEST Paul Eggert wrote:
> > On 5/12/20 10:49 AM, Kamil Dudka wrote:
> ...
> > >> I doubt whether it's a good idea to apply downstream patches that mean
> > >> you
> > >> are running differently from
On Tuesday, May 12, 2020 11:58:49 PM CEST Paul Eggert wrote:
> On 5/12/20 10:49 AM, Kamil Dudka wrote:
> > The problem is that such
> > false positives may easily turn out into true positives, as the code gets
> > changed, and nobody will notice it.
>
> Sounds extremely unlikely here. It's never
On 5/12/20 10:49 AM, Kamil Dudka wrote:
> The problem is that such
> false positives may easily turn out into true positives, as the code gets
> changed, and nobody will notice it.
Sounds extremely unlikely here. It's never happened with coreutils as far as I
know. For this particular case,
On Tuesday, May 12, 2020 6:23:33 PM CEST Paul Eggert wrote:
> 3. If you don't like false alarms from GCC or from other static analyzers,
> filter them out (or get better analyzers...). You can filter in many
> different ways (e.g., by comparing the warnings you got last time from the
> ones you
On 5/11/20 2:11 PM, Bruno Haible wrote:
> xmalloc.c:113:10: warning: use of possibly-NULL '' where non-null
> expected [CWE-690] [-Wanalyzer-possible-null-argument]
> Since xmalloc (0) may be NULL, xmemdup may end up calling memcpy (NULL, p, 0).
> We know this is harmless, if no sanitizer is
On 5/12/20 8:17 AM, Kamil Dudka wrote:
> Pádraig Brady suggested me to run static analyzers with -Dlint, which is
> exactly opposite of what you are saying, isn't it?
That depends on how you're building. I am assuming that you want your static
analyzers to analyze the code that you're actually
Kamil Dudka wrote:
> So you assume that your code is perfect while the tools failing to analyze it
> properly are buggy.
I don't _assume_ it. It's my _experience_ with gnulib code:
* My experience with Coverity is about 20% good findings and 80% that I can
ignore.
* My experience with
On Monday, May 11, 2020 7:26:34 PM CEST Paul Eggert wrote:
> On 5/11/20 12:43 AM, Kamil Dudka wrote:
> > It is usually bad idea to use different versions of source code for
> > compilers and for static analyzers.
>
> Yes, I don't like it either. The patch I installed was particularly bad,
> since
On Monday, May 11, 2020 9:17:39 PM CEST Bruno Haible wrote:
> I agree with Paul, for three reasons:
>
> * We, the developers, should decide how our programs look like. It's not
> only a question of pride - even if that pride is only about having save a
> 'xorl %eax,%eax' instruction. It's a
> Find attached a log built with -DGCC_LINT.
I've looked through part of the reports and found the following:
1) Interesting findings:
xmalloc.c:113:10: warning: use of possibly-NULL '' where non-null
expected [CWE-690] [-Wanalyzer-possible-null-argument]
Since xmalloc (0) may be NULL,
I agree with Paul, for three reasons:
* We, the developers, should decide how our programs look like. It's not
only a question of pride - even if that pride is only about having save a
'xorl %eax,%eax' instruction. It's a question about whether we use the
tools for our benefit, or we become
On 5/11/20 12:43 AM, Kamil Dudka wrote:
> It is usually bad idea to use different versions of source code for compilers
> and for static analyzers.
Yes, I don't like it either. The patch I installed was particularly bad, since
the workaround code was buggy. My only excuse is that the GCC bug
On Sunday, May 10, 2020 3:13:41 AM CEST Paul Eggert wrote:
> The first bug in that output:
>
> cc1: warning: function may return address of local variable
> [-Wreturn-local-addr] lib/careadlinkat.c:73:8: note: declared here
>73 | char stack_buf[1024];
>
> |^
>
> This
On 5/9/20 6:13 PM, Paul Eggert wrote:
> perhaps it'd be better to disable -Wreturn-local-addr instead, at least for
> this
> compilation unit.
I tried doing that, but with GCC 10.1.0 one cannot disable the warning with a
#pragma! So the GCC bug is pretty bad.
I installed the attached to try to
Paul Eggert wrote:
> This false alarm is because the program was built without GCC_LINT being
> defined.
Find attached a log built with -DGCC_LINT.
> If you build with -DGCC_LINT the false alarm should go away.
Indeed, the diffseq.h warning goes away.
Bruno
fanalyze-log.xz
Description:
The first bug in that output:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
lib/careadlinkat.c:73:8: note: declared here
73 | char stack_buf[1024];
|^
This is a false alarm. I installed the attached patch to pacify GCC (if you
build
Hi all, volunteers,
GCC 10 has a new static analysis pass [1][2]. I compiled a gnulib testdir with
CC="gcc -fanalyze". Find attached the part of the log that compiles the gllib/
directory. (The log of the gltests/ directory is uninteresting: here gcc reports
mostly cases wh
21 matches
Mail list logo
