From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Behun <marek.behun@nic.cz>
Date: Mon, 2 Nov 2020 00:06:56 +0100
Subject: [PATCH 4/4] fs: btrfs: initialize @ii in show_dir() to make
 coverity happy
In-Reply-To: <20201031010752.23974-5-wqu@suse.com>
References: <20201031010752.23974-1-wqu@suse.com>
 <20201031010752.23974-5-wqu@suse.com>
Message-ID: <20201102000656.241101c5@nic.cz>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.