[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] vfio-pci: Cleanup error_reports
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH] vfio-pci: Cleanup error_reports |
Date: |
Thu, 05 Sep 2013 17:02:22 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 |
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
signature.asc
Description: OpenPGP digital signature