Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756588AbZGPNeJ (ORCPT ); Thu, 16 Jul 2009 09:34:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756296AbZGPNeI (ORCPT ); Thu, 16 Jul 2009 09:34:08 -0400 Received: from cantor.suse.de ([195.135.220.2]:38977 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755510AbZGPNeH (ORCPT ); Thu, 16 Jul 2009 09:34:07 -0400 Date: Thu, 16 Jul 2009 15:34:06 +0200 Message-ID: From: Takashi Iwai To: Mark Brown Cc: Subrata Modak , Jaswinder Singh Rajput , Jaroslav Kysela , alsa-devel@alsa-project.org, Sachin P Sant , David Howells , Balbir Singh , LKML Subject: Re: [PATCH 01/06] Fix compilation warning for sound/soc/codecs/wm8400.c In-Reply-To: <20090716132308.GC9656@rakim.wolfsonmicro.main> References: <20090716130958.28045.71072.sendpatchset@subratamodak.linux.ibm.com> <20090716132308.GC9656@rakim.wolfsonmicro.main> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.3 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1724 Lines: 43 At Thu, 16 Jul 2009 14:23:08 +0100, Mark Brown wrote: > > 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. I get compile warnings on gcc 4.4.0, too. > 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. Agreed. Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/