Re: [PATCH 0/30] return statement cleanup - kill pointless parentheses (fwd)

Re: [PATCH 0/30] return statement cleanup - kill pointless parentheses (fwd)

[Pavel Machek]

Hi!

Parenthesis around returns statements were driving me crazy for quite
a long time -- return is not a function and I do not think it should
look as one. Could we get this applied?
								Pavel

Signed-off-by: Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>
Signed-off-by: Jesper Juhl <juhl-lkml-poRShpWsAiE@public.gmane.org>

diff -upr linux-2.6.10-rc3-bk13-orig/drivers/acpi/asus_acpi.c linux-2.6.10-rc3-bk13/drivers/acpi/asus_acpi.c
--- linux-2.6.10-rc3-bk13-orig/drivers/acpi/asus_acpi.c	2004-10-18 23:53:46.000000000 +0200
+++ linux-2.6.10-rc3-bk13/drivers/acpi/asus_acpi.c	2004-12-20 23:35:32.000000000 +0100
@@ -656,7 +656,7 @@ static int get_lcd_state(void)
 			lcd = out_obj.integer.value >> 8;
 	}
 	
-	return (lcd & 1);
+	return lcd & 1;
 }
 
 static int set_lcd_state(int value)
@@ -866,7 +866,7 @@ static int __init asus_hotk_add_fs(struc
 
 	acpi_device_dir(device) = asus_proc_dir;
 	if (!acpi_device_dir(device))
-		return(-ENODEV);
+		return -ENODEV;
 
 	proc = create_proc_entry(PROC_INFO, mode, acpi_device_dir(device));
 	if (proc) {
@@ -1098,16 +1098,16 @@ static int __init asus_hotk_check(void)
 
 	result = acpi_bus_get_status(hotk->device);
 	if (result)
-		return(result);
+		return result;
 
 	if (hotk->device->status.present) {
 		result = asus_hotk_get_info();
 	} else {
 		printk(KERN_ERR "  Hotkey device not present, aborting\n");
-		return(-EINVAL);
+		return -EINVAL;
 	}
 
-	return(result);
+	return result;
 }
 
 
@@ -1117,7 +1117,7 @@ static int __init asus_hotk_add(struct a
 	int result;
 
 	if (!device)
-		return(-EINVAL);
+		return -EINVAL;
 
 	printk(KERN_NOTICE "Asus Laptop ACPI Extras version %s\n",
 	       ASUS_ACPI_VERSION);
@@ -1125,7 +1125,7 @@ static int __init asus_hotk_add(struct a
 	hotk =
 	    (struct asus_hotk *) kmalloc(sizeof(struct asus_hotk), GFP_KERNEL);
 	if (!hotk)
-		return(-ENOMEM);
+		return -ENOMEM;
 	memset(hotk, 0, sizeof(struct asus_hotk));
 
 	hotk->handle = device->handle;
@@ -1173,7 +1173,7 @@ static int __init asus_hotk_add(struct a
 		kfree(hotk);
 	}
 
-	return(result);
+	return result;
 }
 
 
@@ -1182,7 +1182,7 @@ static int asus_hotk_remove(struct acpi_
 	acpi_status status = 0;
 
 	if (!device || !acpi_driver_data(device))
-		return(-EINVAL);
+		return -EINVAL;
 
 	status = acpi_remove_notify_handler(hotk->handle, ACPI_SYSTEM_NOTIFY,
 					    asus_hotk_notify);
@@ -1193,7 +1193,7 @@ static int asus_hotk_remove(struct acpi_
 
 	kfree(hotk);
 
-	return(0);
+	return 0;
 }
 
 
diff -upr linux-2.6.10-rc3-bk13-orig/drivers/acpi/osl.c linux-2.6.10-rc3-bk13/drivers/acpi/osl.c
--- linux-2.6.10-rc3-bk13-orig/drivers/acpi/osl.c	2004-12-06 22:24:26.000000000 +0100
+++ linux-2.6.10-rc3-bk13/drivers/acpi/osl.c	2004-12-20 23:40:29.000000000 +0100
@@ -356,7 +356,7 @@ acpi_os_get_timer (void)
 	if (!t)
 		printk(KERN_ERR PREFIX "acpi_os_get_timer() TBD\n");
 
-	return(++t);
+	return ++t;
 }
 
 acpi_status
@@ -529,7 +529,7 @@ acpi_os_read_pci_configuration (struct a
 				PCI_DEVFN(pci_id->device, pci_id->function),
 				reg, size, value);
 
-	return (result ? AE_ERROR : AE_OK);
+	return result ? AE_ERROR : AE_OK;
 }
 EXPORT_SYMBOL(acpi_os_read_pci_configuration);
 
@@ -558,7 +558,7 @@ acpi_os_write_pci_configuration (struct 
 				PCI_DEVFN(pci_id->device, pci_id->function),
 				reg, size, value);
 
-	return (result ? AE_ERROR : AE_OK);
+	return result ? AE_ERROR : AE_OK;
 }
 
 /* TODO: Change code to take advantage of driver model more */
@@ -635,7 +635,7 @@ acpi_os_write_pci_configuration (
 	acpi_integer		value,
 	u32			width)
 {
-	return (AE_SUPPORT);
+	return AE_SUPPORT;
 }
 
 acpi_status
@@ -645,7 +645,7 @@ acpi_os_read_pci_configuration (
 	void			*value,
 	u32			width)
 {
-	return (AE_SUPPORT);
+	return AE_SUPPORT;
 }
 
 void
diff -upr linux-2.6.10-rc3-bk13-orig/drivers/acpi/pci_link.c linux-2.6.10-rc3-bk13/drivers/acpi/pci_link.c
--- linux-2.6.10-rc3-bk13-orig/drivers/acpi/pci_link.c	2004-12-06 22:24:27.000000000 +0100
+++ linux-2.6.10-rc3-bk13/drivers/acpi/pci_link.c	2004-12-20 23:42:13.000000000 +0100
@@ -810,7 +810,7 @@ void acpi_penalize_isa_irq(int irq)
  */
 static int __init acpi_irq_isa(char *str)
 {
-	return(acpi_irq_penalty_update(str, 1));
+	return acpi_irq_penalty_update(str, 1);
 }
 __setup("acpi_irq_isa=", acpi_irq_isa);
 
@@ -821,7 +821,7 @@ __setup("acpi_irq_isa=", acpi_irq_isa);
  */
 static int __init acpi_irq_pci(char *str)
 {
-	return(acpi_irq_penalty_update(str, 0));
+	return acpi_irq_penalty_update(str, 0);
 }
 __setup("acpi_irq_pci=", acpi_irq_pci);
 
diff -upr linux-2.6.10-rc3-bk13-orig/drivers/acpi/processor.c linux-2.6.10-rc3-bk13/drivers/acpi/processor.c
--- linux-2.6.10-rc3-bk13-orig/drivers/acpi/processor.c	2004-12-06 22:24:27.000000000 +0100
+++ linux-2.6.10-rc3-bk13/drivers/acpi/processor.c	2004-12-20 23:49:48.000000000 +0100
@@ -293,9 +293,9 @@ ticks_elapsed (
 	u32			t2)
 {
 	if (t2 >= t1)
-		return (t2 - t1);
+		return t2 - t1;
 	else if (!acpi_fadt.tmr_val_ext)
-		return (((0x00FFFFFF - t1) + t2) & 0x00FFFFFF);
+		return ((0x00FFFFFF - t1) + t2) & 0x00FFFFFF;
 	else
 		return ((0xFFFFFFFF - t1) + t2);
 }
@@ -874,7 +874,7 @@ static int acpi_processor_ppc_has_change
 {
 	int ret = acpi_processor_get_platform_limit(pr);
 	if (ret < 0)
-		return (ret);
+		return ret;
 	else
 		return cpufreq_update_policy(pr->id);
 }
Only in linux-2.6.10-rc3-bk13/drivers/acpi/: returns.txt
diff -upr linux-2.6.10-rc3-bk13-orig/drivers/acpi/tables.c linux-2.6.10-rc3-bk13/drivers/acpi/tables.c
--- linux-2.6.10-rc3-bk13-orig/drivers/acpi/tables.c	2004-10-18 23:53:51.000000000 +0200
+++ linux-2.6.10-rc3-bk13/drivers/acpi/tables.c	2004-12-20 23:51:53.000000000 +0100
@@ -233,7 +233,7 @@ acpi_table_compute_checksum (
 	while (remains--)
 		sum += *p++;
 
-	return (sum & 0xFF);
+	return sum & 0xFF;
 }
 
 /*
diff -upr linux-2.6.10-rc3-bk13-orig/drivers/acpi/toshiba_acpi.c linux-2.6.10-rc3-bk13/drivers/acpi/toshiba_acpi.c
--- linux-2.6.10-rc3-bk13-orig/drivers/acpi/toshiba_acpi.c	2004-10-18 23:53:10.000000000 +0200
+++ linux-2.6.10-rc3-bk13/drivers/acpi/toshiba_acpi.c	2004-12-20 23:46:15.000000000 +0100
@@ -508,7 +508,7 @@ add_device(void)
 			proc->write_proc = (write_proc_t*)dispatch_write;
 	}
 
-	return(AE_OK);
+	return AE_OK;
 }
 
 static acpi_status __exit
@@ -518,7 +518,7 @@ remove_device(void)
 
 	for (item = proc_items; item->name; ++item)
 		remove_proc_entry(item->name, toshiba_proc_dir);
-	return(AE_OK);
+	return AE_OK;
 }
 
 static int __init


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

RE: [PATCH 0/30] return statement cleanup - kill pointless parentheses (fwd)

[Brown, Len]

 
>Parenthesis around returns statements were driving me crazy for quite
>a long time -- return is not a function and I do not think it should
>look as one. Could we get this applied?

K&R-2 says "Parentheses are often used around the expression, but they
are optional."

Groping around the kernel, it seems that about 10% of return statements
use these optional parentheses.

If we modify these, are we going to modify the other 10,000 instances
or is that what your other 29 patches do?

-Len


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

Re: [PATCH 0/30] return statement cleanup - kill pointless parentheses (fwd)

[Jesper Juhl]

Brown, Len wrote:
>  
> 
>>Parenthesis around returns statements were driving me crazy for quite
>>a long time -- return is not a function and I do not think it should
>>look as one. Could we get this applied?
> 
> 
> K&R-2 says "Parentheses are often used around the expression, but they
> are optional."
> 
> Groping around the kernel, it seems that about 10% of return statements
> use these optional parentheses.
> 
> If we modify these, are we going to modify the other 10,000 instances
> or is that what your other 29 patches do?
> 
I had originally planned to do just that, but people on LKML responded 
with "only submit such cleanups via maintainers who actually want them", 
so I gave up on most of it again and just created this one patch for 
Pavel when he asked for it.

-- 
Jesper Juhl <juhl-lkml-poRShpWsAiE@public.gmane.org>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [PATCH 0/30] return statement cleanup - kill pointless parentheses (fwd)

[Pavel Machek]

Hi!

> >Parenthesis around returns statements were driving me crazy for quite
> >a long time -- return is not a function and I do not think it should
> >look as one. Could we get this applied?
> 
> K&R-2 says "Parentheses are often used around the expression, but they
> are optional."

Of course it is valid C, but return(((((-ENOMEM))))); would be valid
C, too :-). It is also bad, because it makes return look like a
function call.

I'd like to at least get rid of 

	return(a);

form.

	return (a);

is slightly less ugly.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

RE: [PATCH 0/30] return statement cleanup - kill pointless parentheses (fwd)

[Brown, Len]

Parens have never confused me into thinking that 'return'
was anything besides a 'return'.  They don't confuse
my editor either, which correctly colors 'return' as
a key-word either way.

Indeed, for compound expressions, I prefer that the parens be present.

return (a * (b + c));

looks better to me than

return a * (b + c);

For returning simple constants, I agree that no parens
is easier on the eye:

return -ENODEV;

But if this were surrounded by a bunch of code that used
parens, return (-ENODEV); is okay with me too.

I agree that "func(arg)" is common style for invoking
a function, and that "keyword (expr)" is common style
for a keyword followed by an expression.  So I guess if
I had to pick, I too would go with "return (expr)"
rather than no space.

I'll apply the part of the patch consistent with above.

thanks,
-Len


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/