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