public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Subrata Modak <subrata@linux.vnet.ibm.com>
Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>,
	Jaroslav Kysela <erex@perex.cz>,
	alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>,
	Sachin P Sant <sachinp@linux.vnet.ibm.com>,
	David Howells <dhowells@redhat.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/06] Fix compilation warning for sound/soc/codecs/wm8400.c
Date: Thu, 16 Jul 2009 14:23:08 +0100	[thread overview]
Message-ID: <20090716132308.GC9656@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20090716130958.28045.71072.sendpatchset@subratamodak.linux.ibm.com>

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.

  reply	other threads:[~2009-07-16 13:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-16 13:10 Re:[PATCH 01/06] Fix compilation warning for sound/soc/codecs/wm8400.c Subrata Modak
2009-07-16 13:23 ` Mark Brown [this message]
2009-07-16 13:34   ` [PATCH " Takashi Iwai
2009-07-16 13:47     ` [alsa-devel] " Mark Brown
2009-07-16 13:51       ` Takashi Iwai
  -- strict thread matches above, loose matches on Subject: below --
2009-07-15  2:18 Subrata Modak
2009-07-15  4:43 ` Jaswinder Singh Rajput
2009-07-15  8:28   ` Mark Brown

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=20090716132308.GC9656@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=erex@perex.cz \
    --cc=jaswinder@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sachinp@linux.vnet.ibm.com \
    --cc=subrata@linux.vnet.ibm.com \
    --cc=tiwai@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox