Re: [Qemu-trivial] [Qemu-devel] [PATCH v2] tpm_tis: fix format for 64bit variable

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On 03/31/2015 09:05 AM, Stefan Berger wrote:
> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
> ---
>  hw/tpm/tpm_tis.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Eric Blake <eblake@redhat.com>

However;

> 
> diff --git a/hw/tpm/tpm_tis.c b/hw/tpm/tpm_tis.c
> index 815c8ea..3f42982 100644
> --- a/hw/tpm/tpm_tis.c
> +++ b/hw/tpm/tpm_tis.c
> @@ -814,7 +814,7 @@ static void tpm_tis_mmio_write_intern(void *opaque, hwaddr addr,
>              tis->loc[locty].state == TPM_TIS_STATE_COMPLETION) {
>              /* drop the byte */
>          } else {
> -            DPRINTF("tpm_tis: Data to send to TPM: %08x (size=%d)\n",
> +            DPRINTF("tpm_tis: Data to send to TPM: 0x%08" PRIx64 " (size=%d)\n",

This caused me to do a double-take (usually, a variable named 'size' is
size_t, in which case %d is wrong; but here it is 'unsigned size').

Also, there is another suspicious DPRINTF earlier in the function; maybe
it's worth a v3? I'm talking about:

    DPRINTF("tpm_tis: write.%u(%08x) = %08x\n", size, (int)addr,
(uint32_t)val);

but there are some 32-bit platforms where uint32_t is a long, so %x will
cause a compiler warning, as compared to PRIx32.  And if you are just
going to cast, why not cast directly to int; on the other hand, if what
you are printing is truly 64-bit, then why not use %016x instead of %08x
(that is, when printing a 64-bit number, having a minimum of 8 0-padded
bytes doesn't make it easy to distinguish a 10-character from
11-character printout, while consistently padding all output to 16
characters makes alignment easier to spot).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]