linux-kernel.vger.kernel.org archive mirror
 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 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).