Re: [Qemu-devel] [PATCH v2 06/30] trace: Fix parameter types in migration

[Eric Blake]

On 03/14/2017 06:32 AM, Dr. David Alan Gilbert wrote:
> * Eric Blake (address@hidden) wrote:
>> On 03/13/2017 03:07 PM, Dr. David Alan Gilbert wrote:
>>> * Eric Blake (address@hidden) wrote:
>>>> An upcoming patch will let the compiler warn us when we are silently
>>>> losing precision in traces; update the trace definitions to pass
>>>> through the full value at the callsite.
>>>>

>>>
>>> So why is a PRIx64 not the right way to print a __u64 ?
>>
>> Because __u64 is not the same type as uint64_t.  On 64-bit Linux, __u64
>> is 'unsigned long long', while uint64_t is 'unsigned long'.
>>
>>> (I prefer %llx to the horrid PRIx64 syntax, but it still seems weird in 
>>> this case)
>>
>> As it is, I'm not sure if __u64 is always 'unsigned long long' in ALL
>> Linux clients; an even-more-conservative patch would be to switch all
>> callers to use explicit casts to something (like uint64_t or unsigned
>> long long) that we have full control over, rather than passing __u64
>> where we have no control over what type it ultimately resolves to.
> 
> That would be my preference - casting to (uint64_t) at the caller and
> keep this as PRIx64.  We know it's a 64bit value so we should never
> use unsigned long long anywhere for it.

Okay, my next version will insert an explicit cast in any caller that is
otherwise passing a __u64 (since we can't guarantee what type __u64
resolves to, and therefore what format string is appropriate for it).

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

signature.asc
Description: OpenPGP digital signature