Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 30 Dec 2020 08:17:32 +0100
From:   Dominique Martinet <asmadeus@codewreck.org>
To:     YANG LI <abaci-bugfix@linux.alibaba.com>
Cc:     davem@davemloft.net, kuba@kernel.org, ericvh@gmail.com,
        lucho@ionkov.net, v9fs-developer@lists.sourceforge.net,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 9p: fix: Uninitialized variable p.
Message-ID: <20201230071732.GA4256@nautica>
References: <1609310713-84972-1-git-send-email-abaci-bugfix@linux.alibaba.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1609310713-84972-1-git-send-email-abaci-bugfix@linux.alibaba.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

YANG LI wrote on Wed, Dec 30, 2020:
> The pointer p is being used but it isn't being initialized,
> need to assign a NULL to it.

My understanding is p has to be initialized: the only way out of the
while(1) loop below sets it.


I don't mind fixing false positive warnings as it makes maintenance
easier for everyone, but:

 1/ the commit message needs to reflect that and at least name which
tool had a problem with it. I'm tempted to think this case is common
enough that the tool ought to be fixed instead...

 2/ the code needs to work in the p=NULL case if you set it that way
(right now, it doesn't, so in the event the code changes in the future
and there really comes a way to skip initialization this change would
actually hinder bug detection -- it'd need to add a p == NULL check
below, which is going to be useless code, but hopefully compilers will
optimize it away)


Thanks,
-- 
Dominique