From: Marek Behun <marek.behun@nic.cz>
To: u-boot@lists.denx.de
Subject: [PATCH 4/4] fs: btrfs: initialize @ii in show_dir() to make coverity happy
Date: Mon, 2 Nov 2020 00:06:56 +0100 [thread overview]
Message-ID: <20201102000656.241101c5@nic.cz> (raw)
In-Reply-To: <20201031010752.23974-5-wqu@suse.com>
On Sat, 31 Oct 2020 09:07:52 +0800
Qu Wenruo <wqu@suse.com> wrote:
> In show_dir() if we hit file type FT_CHRDEV or FT_BLKDEV, we expect an
> BTRFS_INODE_ITEM_KEY, and for that case, we should have @ii filled with
> data read from disk.
>
> We even have ASSERT() for this purpose, but unfortunately coverity can't
> understand the ASSERT() nor if we get key type BTRFS_INODE_ITEM_KEY,
> previous if() branch must go to the read_extent_buffer() branch to fill
> the @ii.
>
> So to make coverity happy, just initialize the variable @ii to all zero.
WTF. If ASSERT excludes this from happening, coverity should understand
this. We live in 2020. I don't much like the idea to do things just to
get coverity happy if it can't understand and infer from things like
ASSERT.
next prev parent reply other threads:[~2020-11-01 23:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 1:07 [PATCH 0/4] fs: btrfs: coverity fixes Qu Wenruo
2020-10-31 1:07 ` [PATCH 1/4] fs: btrfs: inode: handle uninitialized type before returning it Qu Wenruo
2020-11-01 22:59 ` Marek Behun
2020-11-20 1:36 ` Tom Rini
2020-10-31 1:07 ` [PATCH 2/4] fs: btrfs: volumes: prevent overflow for multiplying Qu Wenruo
2020-11-01 23:02 ` Marek Behun
2020-11-02 0:20 ` Qu Wenruo
2020-11-02 1:06 ` Qu Wenruo
2020-11-02 1:06 ` Qu Wenruo
2021-01-20 21:46 ` Tom Rini
2020-10-31 1:07 ` [PATCH 3/4] fs: btrfs: initialize @ret to 0 to prevent uninitialized return value Qu Wenruo
2020-11-01 23:03 ` Marek Behun
2020-11-20 1:36 ` Tom Rini
2020-10-31 1:07 ` [PATCH 4/4] fs: btrfs: initialize @ii in show_dir() to make coverity happy Qu Wenruo
2020-11-01 23:06 ` Marek Behun [this message]
2020-11-02 0:27 ` Qu Wenruo
2020-11-02 7:24 ` Marek Behun
2020-11-02 7:27 ` Qu Wenruo
2020-11-02 20:17 ` Tom Rini
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201102000656.241101c5@nic.cz \
--to=marek.behun@nic.cz \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.