Messages in this thread | | | Date | Sun, 5 Oct 2008 16:48:49 -0700 | From | "Steven Noonan" <> | Subject | Re: [PATCH] sdhci: 'scratch' may be used uninitialized |
| |
On Sun, Oct 5, 2008 at 4:16 PM, Adrian Bunk <bunk@kernel.org> wrote: > On Sun, Oct 05, 2008 at 03:53:28PM -0700, Steven Noonan wrote: >> On Sun, Oct 5, 2008 at 7:28 AM, Adrian Bunk <bunk@kernel.org> wrote: >> > On Wed, Oct 01, 2008 at 01:50:25AM -0700, Steven Noonan wrote: >> >> The variable 'scratch' is always initialized before it's used. The >> >> conditional which is responsible for initialization of 'scratch' will >> >> always evaluate 'true' when the first loop iteration occurs, and thus, >> >> it's properly initialized. GCC doesn't see this, of course, so using >> >> the uninitialized_var() macro seems to work for silencing this case. >> >> >> >> Signed-off-by: Steven Noonan <steven@uplinklabs.net> >> >> --- >> >> drivers/mmc/host/sdhci.c | 2 +- >> >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> >> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c >> >> index e3a8133..6257677 100644 >> >> --- a/drivers/mmc/host/sdhci.c >> >> +++ b/drivers/mmc/host/sdhci.c >> >> @@ -177,7 +177,7 @@ static void sdhci_read_block_pio(struct sdhci_host *host) >> >> { >> >> unsigned long flags; >> >> size_t blksize, len, chunk; >> >> - u32 scratch; >> >> + u32 uninitialized_var(scratch); >> >>... >> > >> > With which gcc version? >> > >> > I'm not getting this warning with gcc 4.3, and IMHO it doesn't make >> > sense to clutter the source code with such workarounds for older gcc >> > versions (we officially support 6 years old compilers, and warning-free >> > compilations with all of them are not reasonably possible). >> > >> > cu >> > Adrian >> >> I've seen it on GCC 4.1 and 4.2. Since lots of distributions still >> haven't marked GCC >4.1 stable, it makes sense to me to kill warnings >> for GCC 4.1 and above. I don't know of any current distribution >> releases using less than GCC 4.1 at the moment. > > It will clutter our code with these workarounds forever. > > And due to silencing these false warnings we will no longer get a > warning when one of them becomes a real bug. > > Working on the remaining warnings that are visible with gcc 4.3 is a > worthwhile goal, but I see no point for silencing some warnings that > only occur with older gcc versions (especially as long as warnings > that are present with all gcc versions stay unfixed). > I feel like there's a logical fallacy here. Sure, we can fix GCC 4.3 warnings, but what about when GCC 4.3 becomes an "old version"? uninitialized_var and other such workarounds will still exist in the code. It seems like the logical progression of your argument should be to never fix false warnings.
- Steven
| |