linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [patch] udb_printf() formatting attribute
@ 2006-05-17 15:04 Jimi Xenidis
  2006-05-17 16:00 ` Nathan Lynch
  0 siblings, 1 reply; 4+ messages in thread
From: Jimi Xenidis @ 2006-05-17 15:04 UTC (permalink / raw)
  To: linuxppc-dev

This patch allows the compiler to catch any printf-like mismatches  
for udbg_printf().
After some brute force building I've only found issues with my own  
code and lparcfg.c
It could break some developers, but IMHO that would be goodness.

Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
---
diff -r 0163968f7fce arch/powerpc/kernel/lparcfg.c
--- a/arch/powerpc/kernel/lparcfg.c	Tue May 16 15:55:19 2006 -0400
+++ b/arch/powerpc/kernel/lparcfg.c	Wed May 17 10:43:55 2006 -0400
@@ -521,10 +521,10 @@ static ssize_t lparcfg_write(struct file
	current_weight = (resource >> 5 * 8) & 0xFF;
-	pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
+	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
		 __FUNCTION__, current_entitled, current_weight);
-	pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
+	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
		 __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
	retval = plpar_hcall_norets(H_SET_PPP, *new_entitled_ptr,
diff -r 0163968f7fce include/asm-powerpc/udbg.h
--- a/include/asm-powerpc/udbg.h	Tue May 16 15:55:19 2006 -0400
+++ b/include/asm-powerpc/udbg.h	Wed May 17 10:43:55 2006 -0400
@@ -23,7 +23,8 @@ extern int udbg_read(char *buf, int bufl
extern int udbg_read(char *buf, int buflen);
extern void register_early_udbg_console(void);
-extern void udbg_printf(const char *fmt, ...);
+extern void udbg_printf(const char *fmt, ...)
+	__attribute__ ((format (printf, 1, 2)));
extern void udbg_progress(char *s, unsigned short hex);
extern void udbg_init_uart(void __iomem *comport, unsigned int speed,

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] udb_printf() formatting attribute
  2006-05-17 15:04 [patch] udb_printf() formatting attribute Jimi Xenidis
@ 2006-05-17 16:00 ` Nathan Lynch
  2006-05-17 18:30   ` Jimi Xenidis
  2006-05-17 18:31   ` Jimi Xenidis
  0 siblings, 2 replies; 4+ messages in thread
From: Nathan Lynch @ 2006-05-17 16:00 UTC (permalink / raw)
  To: Jimi Xenidis; +Cc: linuxppc-dev

Jimi Xenidis wrote:
> This patch allows the compiler to catch any printf-like mismatches  
> for udbg_printf().
> After some brute force building I've only found issues with my own  
> code and lparcfg.c
> It could break some developers, but IMHO that would be goodness.
> 
> Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
> ---
> diff -r 0163968f7fce arch/powerpc/kernel/lparcfg.c
> --- a/arch/powerpc/kernel/lparcfg.c	Tue May 16 15:55:19 2006 -0400
> +++ b/arch/powerpc/kernel/lparcfg.c	Wed May 17 10:43:55 2006 -0400
> @@ -521,10 +521,10 @@ static ssize_t lparcfg_write(struct file
> 	current_weight = (resource >> 5 * 8) & 0xFF;
> -	pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
> +	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
> 		 __FUNCTION__, current_entitled, current_weight);
> -	pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
> +	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
> 		 __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
> 	retval = plpar_hcall_norets(H_SET_PPP, *new_entitled_ptr,

Does this really fix a bug?  What warnings are you able to get gcc to
emit?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] udb_printf() formatting attribute
  2006-05-17 16:00 ` Nathan Lynch
@ 2006-05-17 18:30   ` Jimi Xenidis
  2006-05-17 18:31   ` Jimi Xenidis
  1 sibling, 0 replies; 4+ messages in thread
From: Jimi Xenidis @ 2006-05-17 18:30 UTC (permalink / raw)
  To: Nathan Lynch; +Cc: linuxppc-dev


On May 17, 2006, at 12:00 PM, Nathan Lynch wrote:

> Jimi Xenidis wrote:
>> This patch allows the compiler to catch any printf-like mismatches
>> for udbg_printf().
>> After some brute force building I've only found issues with my own
>> code and lparcfg.c
>> It could break some developers, but IMHO that would be goodness.
>>
>> Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
>> ---
>> diff -r 0163968f7fce arch/powerpc/kernel/lparcfg.c
>> --- a/arch/powerpc/kernel/lparcfg.c	Tue May 16 15:55:19 2006 -0400
>> +++ b/arch/powerpc/kernel/lparcfg.c	Wed May 17 10:43:55 2006 -0400
>> @@ -521,10 +521,10 @@ static ssize_t lparcfg_write(struct file
>> 	current_weight = (resource >> 5 * 8) & 0xFF;
>> -	pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
>> +	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
>> 		 __FUNCTION__, current_entitled, current_weight);
>> -	pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
>> +	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
>> 		 __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
>> 	retval = plpar_hcall_norets(H_SET_PPP, *new_entitled_ptr,
>
> Does this really fix a bug?  What warnings are you able to get gcc to
> emit?
>
My sniff test that resulted in this patch was a manual build of all  
arch/powerpc dirs with -DDEBUG added to CFLAGS.
To see these particular warnings simply add a #define DEBUG before  
the includes of this file you will get:
.../linux-2.6/arch/powerpc/kernel/lparcfg.c: In function  
`lparcfg_write':
.../linux-2.6/arch/powerpc/kernel/lparcfg.c:524: warning: long  
unsigned int format, different type arg (arg 4)
.../linux-2.6/arch/powerpc/kernel/lparcfg.c:527: warning: long  
unsigned int format, different type arg (arg 4)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] udb_printf() formatting attribute
  2006-05-17 16:00 ` Nathan Lynch
  2006-05-17 18:30   ` Jimi Xenidis
@ 2006-05-17 18:31   ` Jimi Xenidis
  1 sibling, 0 replies; 4+ messages in thread
From: Jimi Xenidis @ 2006-05-17 18:31 UTC (permalink / raw)
  To: Nathan Lynch; +Cc: linuxppc-dev


On May 17, 2006, at 12:00 PM, Nathan Lynch wrote:

> Jimi Xenidis wrote:
>> This patch allows the compiler to catch any printf-like mismatches
>> for udbg_printf().
>> After some brute force building I've only found issues with my own
>> code and lparcfg.c
>> It could break some developers, but IMHO that would be goodness.
>>
>> Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
>> ---
>> diff -r 0163968f7fce arch/powerpc/kernel/lparcfg.c
>> --- a/arch/powerpc/kernel/lparcfg.c	Tue May 16 15:55:19 2006 -0400
>> +++ b/arch/powerpc/kernel/lparcfg.c	Wed May 17 10:43:55 2006 -0400
>> @@ -521,10 +521,10 @@ static ssize_t lparcfg_write(struct file
>> 	current_weight = (resource >> 5 * 8) & 0xFF;
>> -	pr_debug("%s: current_entitled = %lu, current_weight = %lu\n",
>> +	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
>> 		 __FUNCTION__, current_entitled, current_weight);
>> -	pr_debug("%s: new_entitled = %lu, new_weight = %lu\n",
>> +	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
>> 		 __FUNCTION__, *new_entitled_ptr, *new_weight_ptr);
>> 	retval = plpar_hcall_norets(H_SET_PPP, *new_entitled_ptr,
>
> Does this really fix a bug?  What warnings are you able to get gcc to
> emit?
>
My sniff test that resulted in this patch was a manual build of all  
arch/powerpc dirs with -DDEBUG added to CFLAGS.
To see these particular warnings simply add a #define DEBUG before  
the includes of this file you will get:
.../linux-2.6/arch/powerpc/kernel/lparcfg.c: In function  
`lparcfg_write':
.../linux-2.6/arch/powerpc/kernel/lparcfg.c:524: warning: long  
unsigned int format, different type arg (arg 4)
.../linux-2.6/arch/powerpc/kernel/lparcfg.c:527: warning: long  
unsigned int format, different type arg (arg 4)

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-05-17 18:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-17 15:04 [patch] udb_printf() formatting attribute Jimi Xenidis
2006-05-17 16:00 ` Nathan Lynch
2006-05-17 18:30   ` Jimi Xenidis
2006-05-17 18:31   ` Jimi Xenidis

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).