Re: failure to build due to ignoring fwrite() result

[Jim Meyering]

Paul Eggert wrote:
> On 08/30/10 12:52, Jim Meyering wrote:
>> However, for the vast majority of the functions marked with this
>> attribute, ignoring the return value really is a bug in all but a
>> very small fraction of the use cases.
>
> That may well be, but that's not the issue.  The issue is whether
> the cost of using -Wunused-result exceeds its benefits.  The cost
> accrues in the cases where it's not a bug to ignore
> the returned value, possibly because it's a function like
> fwrite or strtod that should never have been marked with
> __attribute__ ((__warn_unused_result__)).  The benefit accrues
> in the cases where using -Wunused-result catches significant bugs
> that would not be caught otherwise.
>
> For poorly-written code, -Wunused-result may well be a good thing.
> For well-written code, such as is found in coreutils and gnulib,
> it's not at all clear that the benefits exceed the cost, and we
> do have guidance from the GNU coding standards to steer clear of
> this sort of thing.
>
> Is there some way that we can get the benefits of -Wunused-result
> without cluttering up the code with ignore_value and ignore_ptr?
> For example, can we list separately, outside the code, which
> diagnostics to ignore?

Even good drivers appreciate having a seat belt and airbags.

For coreutils and gnulib it's not a big deal, since
there are only 8 uses of ignore_value and ignore_ptr in each
(not counting a bunch in gnulib/tests).

That said, if there is a way to tell gcc to ignore
a particular otherwise-offending WUR warning without
cluttering up our code, I'd be interested.

> This reminds me of similar arguments that one should never use
> strcpy, but should always use strlcpy because it's "safer".
> Again, for poorly-written code that may be true, but for
> well-written code strlcpy is likely to introduce more bugs than
> it cures.  (See <http://en.wikipedia.org/wiki/Strlcpy> for more
> on this even-more-controversial topic.)