On 09/05/2013 04:41 PM, Alex Williamson wrote:

>>>          /* This can fail for an old kernel or legacy PCI dev */
>>> -        DPRINTF("VFIO_DEVICE_GET_IRQ_INFO failure ret=%d\n", ret);
>>> +        DPRINTF("VFIO_DEVICE_GET_IRQ_INFO failure: %m\n");
>>
>> %m is a glibc extension, and does not exist on all platforms.  You
>> should probably not make this change.
> 
> It's not the only instance of %m in this file and, IIRC, was previously
> suggested by Anthony.  Are we banning %m now?  Thanks,

This particular usage is protected by DPRINTF, so as long as DPRINTF is
disabled, it won't break compilation on non-glibc systems.  And in
thinking about it, this _particular_ file is Linux-only (vfio is a Linux
kernel concept not available on other OS), so for _this_ file, you are
assured that %m will always be interpreted by glibc (or its derivatives)
and thus have defined extension behavior.  So I retract any complaint
about this patch.

But I suspect that if we start encouraging the use of %m, we will
eventually proliferate it into other files that are not Linux-only, and
then run into compilers that warn about unknown format specifiers for a
given platform (such as on BSD systems), or worse, silent compilation
but then output that triggers undefined behavior if the printf is ever
actually used at runtime (typically you'd get a literal %m instead of
the intended strerror() text which merely makes the trace less useful,
but undefined behavior also permits a libc that abort()s on seeing %m...)

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