Re: [Xen-devel] [PATCH] printk: prefer %#x et at over 0x%x

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-09-21 at 12:28 +0100, Jan Beulich wrote:
> --- 2012-09-21.orig/xen/arch/x86/apic.c 2012-09-17 09:57:54.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/apic.c      2012-09-21 10:54:46.000000000 +0200
> @@ -689,7 +689,7 @@ void __devinit setup_local_APIC(void)
>          value = apic_read(APIC_ESR);
>          if (value != oldvalue)
>              apic_printk(APIC_VERBOSE, "ESR value before enabling "
> -                        "vector: 0x%08lx  after: 0x%08lx\n",
> +                        "vector: %#lx  after: %#lx\n",

This is dropping the 0 padding?

Perhaps deliberate, I just mention it because of my next comment...

> --- 2012-09-21.orig/xen/arch/x86/cpu/mcheck/vmce.c      2012-08-08 
> 08:20:09.000000000 +0200
> +++ 2012-09-21/xen/arch/x86/cpu/mcheck/vmce.c   2012-09-21 10:54:46.000000000 
> +0200
> @@ -88,7 +88,7 @@ static int bank_mce_rdmsr(const struct v
>      case MSR_IA32_MC0_CTL:
>          /* stick all 1's to MCi_CTL */
>          *val = ~0UL;
> -        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
> +        mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL %#"PRIx64"\n",

PRIx64 is something like "016llx".

Tim pointed out to me that "%#010x" renders the number 0 as 0000000000
rather than 0x00000000 which was more likely what was desired.

This is apparently a deliberate "feature" of printf (or at least it is
standardized)

Also in the %#"PRIx64" case the width is 016 which is 2 too few once you
include the 0x.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel