From: Ingo Molnar <mingo@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Corey Minyard <cminyard@mvista.com>,
minyard@acm.org, Linux Kernel <linux-kernel@vger.kernel.org>,
OpenIPMI Developers <openipmi-developer@lists.sourceforge.net>
Subject: Re: [PATCH v2] Remove uninitialized_var()
Date: Tue, 30 Oct 2012 08:24:16 +0100 [thread overview]
Message-ID: <20121030072416.GA4537@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1210291150470.10845@chino.kir.corp.google.com>
* David Rientjes <rientjes@google.com> wrote:
> On Sun, 28 Oct 2012, Ingo Molnar wrote:
>
> > I left it a bit mystic because in some cases this macro was
> > mis-used not to suppress GCC being wrong, but to hide GCC being
> > *right*: for example unused variable warnings in cases like:
> >
> > int uninitialized_var(var);
> >
> > #ifdef XYZ
> > var = ...;
> > ...
> > #endif
> >
> > which (ab-)use was no doubt actively dangerous beyond being
> > ugly. One such example is in arch/x86/mm/numa.c. (These cases
> > now turn into clear (and always harmless) compiler warnings, as
> > they should.)
> >
>
> I like initializing them to 0 or NULL because it will still
> emit the "unused variable" warnings whereas using
> uninitialized_var() would not with -Wall. It's quite possible
> that uninitialized_var() is actually suppressing this warning
> for variables that aren't used.
Yeah.
> I fixed a bug that was attributed to uninitialized var for rc1
> in 43385846968b ("fs, xattr: fix bug when removing a name not
> in xattr list"), so thanks very much for removing it entirely.
Ok - looks like everyone is happy with this version - I'll send
a refreshed version of this patch to Linus near the end of the
v3.8 merge window.
Note, I won't push it out into linux-next for much of the
development window (or at all), as there's very little gain from
all the interaction and churn this would cause with various
trees, nor does it seem necessary to split it up into a hundred
small patches. We'll just pull the trigger before v3.8-rc1 with
one well-tested patch and that's it.
Unless Linus objects to this workflow.
Thanks,
Ingo
next prev parent reply other threads:[~2012-10-30 7:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-16 20:53 IPMI: Some minor fixes minyard
2012-10-16 20:53 ` [PATCH 1/5] IPMI: Remove SMBus driver info from the docs minyard
2012-10-16 20:53 ` [PATCH 2/5] ACPI: Reorder IPMI driver before any other ACPI drivers minyard
2012-10-22 23:45 ` Andrew Morton
2012-10-23 0:00 ` Matthew Garrett
2012-10-23 0:07 ` Andrew Morton
2012-10-23 0:10 ` Matthew Garrett
2012-10-16 20:53 ` [PATCH 3/5] IPMI: Change link order minyard
2012-10-16 20:53 ` [PATCH 4/5] IPMI: Fix some uninitialized warning minyard
2012-10-22 23:49 ` Andrew Morton
2012-10-26 19:35 ` Corey Minyard
2012-10-26 19:41 ` Linus Torvalds
2012-10-27 13:12 ` [PATCH] Remove uninitialized_var() Ingo Molnar
2012-10-27 18:48 ` Andrew Morton
2012-10-28 10:20 ` [PATCH v2] " Ingo Molnar
2012-10-29 0:56 ` Ryan Mallon
2012-10-29 6:36 ` [PATCH v3] " Ingo Molnar
2012-10-29 18:55 ` [PATCH v2] " David Rientjes
2012-10-30 7:24 ` Ingo Molnar [this message]
2012-10-16 20:53 ` [PATCH 5/5] IPMI: Detect register spacing on PCI interfaces minyard
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=20121030072416.GA4537@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cminyard@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=minyard@acm.org \
--cc=openipmi-developer@lists.sourceforge.net \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).