At Thu, 25 Aug 2011 08:10:43 +0200, Alan Barrett <apb%cequrux.com@localhost>
wrote:
Subject: (void) casts when function return values are ignored
>
> Of course the compiler can tell that you don't use the return value.
> But neither the compiler nor a human reader can easily tell that this
> is deliberate, as opposed to a mistake.
Yup. I think the tools can still help here, as I alluded to in a less
concise earlier post.
First step is to teach lint about GCC attributes (or the <sys/cdefs.h>
equivalents) so that it can be smarter (or at least as smart as GCC)
about when to print its warnings with the '-h' option turned on.
Second step is to fix GCC so that it doesn't warn about unused results
of functions annotated with the warn_unused_result attribute when
they're purposefully cast to void. (gcc 4.1.2 and 4.2.1 do warn even
with the void cast, but clang 1.7 does not warn with the void cast)
> Functions with return values fall into a few broad categories:
>
> 1. Functions whose return value contains the result of the
> function; e.g. sqrt(3).
Annotate in the headers with __attribute__((__warn_unused_result__))
(or some more sane <sys/cdefs.h> abbreviation)
> 2. Functions whose return value is used to report success or
> failure; e.g. sscanf(3), write(2).
Leave these ones unannotated and "lint -h" or its more precise
equivalent can be turned on when you want to see them.
> 3. Functions whose return value contains information that is
> uninteresting, or also available elsewhere; e.g. strcpy(3).
Add a "no_warn_unused_result" attribute and annotate these functions
with it.
With all that you should have an environment where normally the compiler
will warn if you accidentally ignore a result in group 1, lint _can_
warn about possible problems in group 2, and neither lint nor the
compiler will make noise about ignored results in group 3.
Then the debate can be whether to appease lint's warnings in group 2
with a void cast or not, without getting all the void-cast naysayers
complaining about how stupid lint is about group 3.
(and of course there will no doubt be lots of debate about which
functions belong in group 3)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpoulaP4X5Xj.pgp
Description: PGP signature