Re: [Qemu-devel] [PULL 02/29] numa: Allow setting NUMA distance for different NUMA nodes

[Eric Blake]

On 05/30/2017 01:10 PM, Eduardo Habkost wrote:
> On Tue, May 30, 2017 at 10:28:21AM -0500, Eric Blake wrote:
>> On 05/30/2017 09:01 AM, Eduardo Habkost wrote:
>>
>>>> The OSX compiler is pickier about format strings than gcc,
>>>> and neither "MAX_NODES" nor "MAX(anything)" are uint16_t type.
>>>
>>> src and dst are both uint16_t, so MAX(src, dst) is also uint16_t,
>>> isn't it?  It looks like MAX_NODES is the problem.
>>
>> No. MAX() invokes arithmetic (both ?: and > operators), and arithmetic
>> involves default promotion (anything shorter than int becomes 'int').
> 
> Oh, I didn't know that.

And the fact that var-arg passing REQUIRES promotion means you CAN'T
tell the difference from a true uint16_t argument and an int argument
which resulted from arithmetic promotion.  Which is why Paolo has argued
that the MacOS compiler warning is bogus because it is overly picky.
But we obviously are in no position to get it changed.

> 
>>
>>> +++ b/numa.c
>>> @@ -232,7 +232,7 @@ static void parse_numa_distance(NumaDistOptions *dist, 
>>> Error **errp)
>>>      if (src >= MAX_NODES || dst >= MAX_NODES) {
>>>          error_setg(errp,
>>>                     "Invalid node %" PRIu16
>>> -                   ", max possible could be %" PRIu16,
>>> +                   ", max possible could be %d",
>>
>> Don't you want %u to match PRIu16, rather than %d?
> 
> Can't this (using %u with an int argument) make more pedantic
> compilers complain?

Yes, gcc's -Wformat-signedness would (probably) flag it.  But we don't
use that.  At any rate, ALL uint16_t values are formatted identically
for both %u and %d, so as long as we have a formula for keeping picky
compilers silent, I don't care beyond that point.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature