bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Paul Eggert
Subject: Re: failure to build due to ignoring fwrite() result
Date: Mon, 30 Aug 2010 13:48:27 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6

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?

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.)



reply via email to

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