All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>
Cc: Pavel Dovgalyuk <dovgaluk@ispras.ru>,
	qemu-devel <qemu-devel@nongnu.org>,
	Pavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>,
	Felipe Franciosi <felipe@nutanix.com>
Subject: Re: [Qemu-devel] [PATCH] replay: Fix build with -Werror=unused-result
Date: Wed, 21 Sep 2016 08:55:47 -0500	[thread overview]
Message-ID: <ead4f524-9281-e80b-e42d-325d39ee8b43@redhat.com> (raw)
In-Reply-To: <87mvj11ljr.fsf@dusky.pond.sub.org>

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

On 09/21/2016 07:31 AM, Markus Armbruster wrote:
>>
>> If we want to ignore return value reliably, lets just pull in the
>> ignore_value macro from gnulib which is known to work across GCC
>> versions
>>
>>
>> /* Normally casting an expression to void discards its value, but GCC
>>    versions 3.4 and newer have __attribute__ ((__warn_unused_result__))
>>    which may cause unwanted diagnostics in that case.  Use __typeof__
>>    and __extension__ to work around the problem, if the workaround is
>>    known to be needed.  */
>> #if 3 < __GNUC__ + (4 <= __GNUC_MINOR__)
>> # define ignore_value(x) \
>>     (__extension__ ({ __typeof__ (x) __x = (x); (void) __x; }))
>> #else
>> # define ignore_value(x) ((void) (x))
>> #endif
> 
> Casting a value to void is the traditional and obvious way to say "yes,
> I mean to ignore this value".  Now compilers start to reply "no, you
> don't".  We can invent new (and less obvious) ways to say "yes, I do",
> and compilers can then learn them so they can again reply "no, you
> don't".  Why have compilers started to behave like two-year-olds?

gcc has been doing the "__warn_unused_value__ means cast-to-void is
insufficient" complaint for years (since at least 2008, per the gnulib
history).  But the gnulib workaround has also been effectively silencing
it for years (it was actually my work in 2011, commit 939dedd, which
came up with the form listed above).  The other nice thing about
"ignore_value(wur_function())" is that you are avoiding a cast in your
local code, and the burden of shutting up the annoying compiler is
hidden behind a macro that can easily be changed to affect all clients
of the macro, should gcc regress yet again and we need some other
formula to shut it up.

And yes, the gnulib mailing list has threads complaining about gcc's
behavior back when the macro had to be invented, and again when glibc
added wur markings to functions that can legitimately be ignored
(fread() is one of them; because there are valid programming paradigms
where you check ferror() later on rather than having to check every
intermediate fread(), at the expense of less-specific error messages).

-- 
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: 604 bytes --]

  reply	other threads:[~2016-09-21 13:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 17:08 [Qemu-devel] [PATCH] replay: Fix build with -Werror=unused-result Felipe Franciosi
2016-09-21  5:17 ` Pavel Dovgalyuk
2016-09-21  6:24   ` Markus Armbruster
2016-09-21 10:00     ` Felipe Franciosi
2016-09-21 10:03       ` Pavel Dovgalyuk
2016-09-21 10:07       ` Daniel P. Berrange
2016-09-21 10:12         ` Felipe Franciosi
2016-09-21 12:28           ` Felipe Franciosi
2016-09-21 12:31         ` Markus Armbruster
2016-09-21 13:55           ` Eric Blake [this message]
2016-09-21 14:26             ` Felipe Franciosi
2016-09-21 14:35               ` Daniel P. Berrange
2016-09-21 14:38                 ` Felipe Franciosi
2016-09-21 14:44                 ` Eric Blake
2016-09-21 15:28                 ` Markus Armbruster
2016-09-21 18:18                   ` Eric Blake
2016-09-22  8:00                     ` Daniel P. Berrange
2016-09-22 11:51                       ` Markus Armbruster
2016-09-22 13:30                         ` Eric Blake
2016-09-23  8:15                           ` Markus Armbruster
2016-09-23 13:02                             ` Felipe Franciosi
2016-09-21 14:42               ` Eric Blake
2016-09-21  9:17 ` no-reply

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=ead4f524-9281-e80b-e42d-325d39ee8b43@redhat.com \
    --to=eblake@redhat.com \
    --cc=Pavel.Dovgaluk@ispras.ru \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dovgaluk@ispras.ru \
    --cc=felipe@nutanix.com \
    --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.