On 03/14/2017 06:32 AM, Dr. David Alan Gilbert wrote: > * Eric Blake (ebl...@redhat.com) wrote: >> On 03/13/2017 03:07 PM, Dr. David Alan Gilbert wrote: >>> * Eric Blake (ebl...@redhat.com) 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
