lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090716132308.GC9656@rakim.wolfsonmicro.main>
Date:	Thu, 16 Jul 2009 14:23:08 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Subrata Modak <subrata@...ux.vnet.ibm.com>
Cc:	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	Jaroslav Kysela <erex@...ex.cz>, alsa-devel@...a-project.org,
	Takashi Iwai <tiwai@...e.de>,
	Sachin P Sant <sachinp@...ux.vnet.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 01/06] Fix compilation warning for
 sound/soc/codecs/wm8400.c

On Thu, Jul 16, 2009 at 06:40:01PM +0530, Subrata Modak wrote:

> How about the following brutal shutdown ?

No, this is the patch you originally submitted.  You are missing the
point here - your patches are all just papering over the warning and
won't help at all if there is an actual problem.

> 'factors' will get initialized here, as, 'freq_out' will probably never have
> a '0' value. So, 'fll_factors()' will actually overwrite values in 'factors'
> even after the initial brutal assignment:
> 	"struct fll_factors factors = {}"

This is pretty much the point of the warning when it's valid - it's
trying to catch situations where there is a code path where the variable
is used without being initialised.  If you just blindly initialise the
variable as you are doing then the warning goes away but any problematic
code remains so the situation is worse.

In this case I suspect that whatever compiler you are using (none of
those I've tried with seem to be doing this) isn't able to figure out
that if we skip initialising the variable then we use exactly the same
condition to return from the function before we try to use the variable.
For something like this the warning can normally be worked around by
changing the control flow so that the compiler is able to figure out
that things are safe.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ