From: Ryan Mallon <rmallon@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
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: Mon, 29 Oct 2012 11:56:35 +1100 [thread overview]
Message-ID: <508DD443.9050505@gmail.com> (raw)
In-Reply-To: <20121028102007.GA7547@gmail.com>
On 28/10/12 21:20, Ingo Molnar wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> On Sat, 27 Oct 2012 15:12:03 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>>
>>> There's 3 types of conversions done:
>>>
>>> uninitialized_var(x) => x = 0 /* for scalar types */
>>> uninitialized_var(x) => x = NULL /* for pointers */
>>> uninitialized_var(x) => x = { } /* for structures, unions */
>>
>> It's regrettable that we lose information.
>> uninitialized_var() says "this isn't needed - it's just there
>> for gcc". The reader can of course work out the reason with
>> careful code inspection, but that's a lot more time consuming.
>>
>> We could go add "/* keep gcc quiet */" to every site, or add
>> self-documenting macros for the above.
>
> Ok, agreed - I've added /* GCC */ to every site to make people
> think about it.
>
> 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.)
Shouldn't those cases be using:
int var __maybe_unused;
To clarify that the variable is not used in some configurations. Or
moving the variable declaration inside the #ifdef block if possible. The
alternative:
#ifdef XYZ
int var;
#endif
...
#ifdef XYZ
var = ...;
#endif
Does get pretty clunky.
>
> This further strengthens the argument that we should remove this
> whole thing.
>
> Thanks,
>
> Ingo
>
> ---
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
<snip>
> 185 files changed, 281 insertions(+), 291 deletions(-)
It might be interesting to know how many instances of uninitialized_var
are no longer required because of code change around them. Possibly
redefining uninitialized_var as an empty macro and then checking how
many don't cause errors would identify if any can just be removed
outright rather than converting them to an assignment.
> diff --git a/arch/arm/mach-sa1100/assabet.c b/arch/arm/mach-sa1100/assabet.c
> index 6a7ad3c..5ec34d6 100644
> --- a/arch/arm/mach-sa1100/assabet.c
> +++ b/arch/arm/mach-sa1100/assabet.c
> @@ -388,7 +388,7 @@ static void __init map_sa1100_gpio_regs( void )
> */
> static void __init get_assabet_scr(void)
> {
> - unsigned long uninitialized_var(scr), i;
> + unsigned long scr = 0 /* GCC */, i;
>
> GPDR |= 0x3fc; /* Configure GPIO 9:2 as outputs */
> GPSR = 0x3fc; /* Write 0xFF to GPIO 9:2 */
> diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
> index 35e106f..2c2da64 100644
> --- a/arch/ia64/kernel/process.c
> +++ b/arch/ia64/kernel/process.c
> @@ -493,7 +493,7 @@ static void
> do_copy_task_regs (struct task_struct *task, struct unw_frame_info *info, void *arg)
> {
> unsigned long mask, sp, nat_bits = 0, ar_rnat, urbs_end, cfm;
> - unsigned long uninitialized_var(ip); /* GCC be quiet */
> + unsigned long ip = 0 /* GCC */; /* GCC be quiet */
Doubled up comment. Same in a few other places.
> elf_greg_t *dst = arg;
> struct pt_regs *pt;
> char nat;
> diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
> index c641333..75cc8da 100644
> --- a/arch/ia64/mm/discontig.c
> +++ b/arch/ia64/mm/discontig.c
> @@ -185,7 +185,7 @@ static void *per_cpu_node_setup(void *cpu_data, int node)
> void __init setup_per_cpu_areas(void)
> {
> struct pcpu_alloc_info *ai;
> - struct pcpu_group_info *uninitialized_var(gi);
> + struct pcpu_group_info *gi = NULL /* GCC */;
The placement of the comment here is a bit ugly, can you change it so it
appears after the semicolon when it is the last initialiser?
~Ryan
next prev parent reply other threads:[~2012-10-29 0:56 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 [this message]
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
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=508DD443.9050505@gmail.com \
--to=rmallon@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cminyard@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=minyard@acm.org \
--cc=openipmi-developer@lists.sourceforge.net \
--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).