All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH] vfio-pci: Cleanup error_reports
Date: Thu, 05 Sep 2013 17:02:22 -0600	[thread overview]
Message-ID: <52290D7E.7020003@redhat.com> (raw)
In-Reply-To: <1378420917.3246.271.camel@ul30vt.home>

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

      reply	other threads:[~2013-09-05 23:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05 22:29 [Qemu-devel] [PATCH] vfio-pci: Cleanup error_reports Alex Williamson
2013-09-05 22:37 ` Eric Blake
2013-09-05 22:41   ` Alex Williamson
2013-09-05 23:02     ` Eric Blake [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52290D7E.7020003@redhat.com \
    --to=eblake@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.