Date: Wed, 9 Sep 2020 08:49:01 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mark Johnston <markj@freebsd.org>, Michal Meloun <meloun.michal@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: uninitialized variables [Was: svn commit: r365445 - head/sys/cam/mmc] Message-ID: <6b18b5ef-a743-3d5e-8dd2-24640614ec88@FreeBSD.org> In-Reply-To: <20200908124848.GB66031@raichu> References: <202009080546.0885kAgk006783@repo.freebsd.org> <34826ee7-12a9-d309-1fee-cd2e95744603@FreeBSD.org> <67be7fa5-30dd-b7ee-1076-9c29195d83d3@gmail.com> <20200908124848.GB66031@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/09/2020 15:48, Mark Johnston wrote:
> I observed the same thing recently as well: the compiler catches
> uninitialized variables only in simple cases. In my case, any uses of
> goto within the function seemed to silence the warning, even if they
> appeared after the uninitialized reference.
I am running a kernel build now with this addition (for clang):
CWARNEXTRA+= -Wconditional-uninitialized -Wno-error-conditional-uninitialized
It produces a ton of warnings.
Some of them are probably false positives, but some look quite reasonable.
E.g.:
sys/cam/cam_periph.c:314:19: warning: variable 'p_drv' may be uninitialized when
used here [-Wconditional-uninitialized]
TAILQ_REMOVE(&(*p_drv)->units, periph, unit_links);
Indeed, there is a conditional 'goto failure' before a first assignment to p_drv
and the line is after the label. So, maybe the situation is impossible, but it
is reasonable to warn about it.
But the number of false positives (and "possible but impossible" situations) is
too overwhelming.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6b18b5ef-a743-3d5e-8dd2-24640614ec88>