[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 06/30] trace: Fix parameter types in migration
Date: Tue, 14 Mar 2017 09:36:47 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]