bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15970: ignore_value vs (void) [was: [Bug-tar] bug#15970: bug#15970:


From: Eric Blake
Subject: bug#15970: ignore_value vs (void) [was: [Bug-tar] bug#15970: bug#15970: Crash in gettext() after fork() on Mac OS X]
Date: Wed, 27 Nov 2013 09:44:06 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

On 11/27/2013 09:30 AM, Joerg Schilling wrote:
>>> Are you using "ignore_value" because of the gcc bug that ignores the 
>>> official
>>> method to tell that the return code is ignored intentionally:
>>>
>>>     (void) write(fd, buf, len);

The C standard does not document that '(void) write(...)' is required to
avoid diagnostics, so I don't see the gcc behavior as a bug (yes, it's
annoying behavior, but that doesn't make it incorrect behavior).

> Do you believe this is the right method to deal with the problem?

We're already stuck with compilers in the wild where casting to void is
insufficient to shut up the compiler warnings, so at this point in time,
any GNU code that wants to avoid warnings is better off using gnulib's
ignore_value() than a cast to void.  At which point, it should not
matter what ignore_value() uses under the hood (personally, I PREFER use
of ignore_value() - function syntax is easier to read as declaring the
intent of what I'm doing than cast syntax, and a coding style that
minimizes casts is preferred).

> It will most likely prevent to create enough pressure on the GCC people to 
> fix 
> the current warning problem.

No, I don't think that gnulib's use of ignore_value() is enough pressure
to make gcc change their warning behavior.  Nor do I care - even if gcc
changes behavior, I still plan on using ignore_value() (and let gnulib
figure out how to map ignore_value to the most efficient semantics for
each compiler it is tested with).

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]