From: Paul Eggert <eggert@cs.ucla.edu>
To: Kamil Dudka <kdudka@redhat.com>
Cc: bug-gnulib@gnu.org
Subject: Re: Coverity false positives triggered by gnulib's implementation of base64
Date: Fri, 10 May 2019 18:36:00 -0500 [thread overview]
Message-ID: <4c740be5-492f-bce5-35cb-8be776207121@cs.ucla.edu> (raw)
In-Reply-To: <29387202.mYf3tFGfHq@kdudka-nb>
On 5/10/19 4:32 AM, Kamil Dudka wrote:
> I do not think it is a good idea to change a piece of working code to make
> a static analysis false positives magically disappear.
I was thinking of making a change only if it makes the code a bit better
even ignoring whether Coverity is used. Surely we wouldn't insist on
slightly-worse code merely because we also want to further clutter it up
with Coverity pacification.
> Getting precise results for checkers like
> this is computationally expensive and in the general case impossible.
Although that is true in general, in this particular case it's easy for
an automated tool with Coverity's sophistication to check that the
subscripts are in-range for the array. This is really a Coverity bug and
I'd rather not add batches of comments to code just to cater to Coverity
bugs. Particularly since Coverity is not free software and ordinary
developers like me cannot use it.This sort of thing would send the wrong
signal from the GNU project.
prev parent reply other threads:[~2019-05-10 23:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 14:22 Coverity false positives triggered by gnulib's implementation of base64 Kamil Dudka
2019-05-08 8:15 ` Bruno Haible
2019-05-09 16:14 ` Kamil Dudka
2019-05-09 20:35 ` Bruno Haible
2019-05-09 21:55 ` Paul Eggert
2019-05-09 22:13 ` Bruno Haible
2019-05-09 22:28 ` Paul Eggert
2019-05-10 11:57 ` Kamil Dudka
2019-05-10 14:11 ` Bruno Haible
2019-05-10 14:32 ` Kamil Dudka
2019-05-10 11:41 ` Kamil Dudka
2019-05-09 19:14 ` Paul Eggert
2019-05-10 11:32 ` Kamil Dudka
2019-05-10 11:34 ` Florian Weimer
2019-05-10 11:51 ` Kamil Dudka
2019-05-10 23:36 ` Paul Eggert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c740be5-492f-bce5-35cb-8be776207121@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=bug-gnulib@gnu.org \
--cc=kdudka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).