All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.