linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Markus Elfring <Markus.Elfring@web.de>,
	kernel-janitors@vger.kernel.org,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Joe Perches <joe@perches.com>, Kees Cook <keescook@chromium.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] string.h: Mark 34 functions with __must_check
Date: Wed, 9 Oct 2019 15:26:18 +0200	[thread overview]
Message-ID: <954c5d70-742f-7b0e-57ad-ea967e93be89@rasmusvillemoes.dk> (raw)
In-Reply-To: <75f70e5e-9ece-d6d1-a2c5-2f3ad79b9ccb@web.de>

On 09/10/2019 14.14, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 9 Oct 2019 13:53:59 +0200
> 
> Several functions return values with which useful data processing
> should be performed. These values must not be ignored then.
> Thus use the annotation “__must_check” in the shown function declarations.

This _might_ make sense for those that are basically kmalloc() wrappers
in one way or another [1]. But what's the point of annotating pure
functions such as strchr, strstr, memchr etc? Nobody is calling those
for their side effects (they don't have any...), so obviously the return
value is used. If somebody does a strcmp() without using the result, so
what? OK, it's odd code that might be worth flagging, but I don't think
that's the kind of thing one accidentally adds. You're also not
consistent - strlen() is not annotated. And, for the standard C
functions, -Wall already seems to warn about an unused call:

 #include <string.h>
int f(const char *s)
{
	strlen(s);
	return 3;
}
$ gcc -Wall -o a.o -c a.c
a.c: In function ‘f’:
a.c:5:2: warning: statement with no effect [-Wunused-value]
  strlen(s);
  ^~~~~~~~~

[1] Just might. The problem is the __must_check does not mean that the
return value must be followed by a comparison to NULL and bailing out
(that can't really be checked), it simply ensures the return value is
assigned somewhere or used in an if(). So foo->bar = kstrdup() not
followed by a check of foo->bar won't warn. So one would essentially
only catch instant-leaks. __must_check is much better suited for
functions that mutate a passed-in or global object, e.g.
start_engine(engine).

Rasmus

  reply	other threads:[~2019-10-09 13:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09 12:14 [PATCH] string.h: Mark 34 functions with __must_check Markus Elfring
2019-10-09 13:26 ` Rasmus Villemoes [this message]
2019-10-09 13:56   ` Dan Carpenter
2019-10-09 14:21     ` Rasmus Villemoes
2019-10-09 14:30       ` Dan Carpenter
2019-10-09 16:31         ` Nick Desaulniers
2019-10-09 18:45           ` Dan Carpenter
2019-10-10  7:20           ` Rasmus Villemoes
2019-10-09 16:37   ` Nick Desaulniers
2019-10-09 16:42   ` Markus Elfring
2019-10-11  5:15   ` Searching for missing variable checks Markus Elfring
2019-10-09 15:09 ` [PATCH] string.h: Mark 34 functions with __must_check Steven Rostedt
2019-10-09 16:13   ` Nick Desaulniers
2019-10-09 16:27     ` Steven Rostedt
2019-10-09 16:40       ` Nick Desaulniers
2019-10-09 17:04         ` Markus Elfring
2019-10-09 17:33           ` Nick Desaulniers
2019-10-09 18:06             ` Markus Elfring
2019-10-09 16:38     ` [PATCH] " Joe Perches
2019-10-09 17:33       ` Nick Desaulniers
2019-10-10 14:27         ` David Sterba
2019-10-10 14:34           ` Joe Perches
2019-10-11  5:00             ` Markus Elfring
2019-10-10 15:46           ` [PATCH] " David Laight
2019-10-09 20:06   ` Markus Elfring
2019-10-10  5:29     ` Andy Shevchenko
2019-10-10  7:25       ` Markus Elfring
2019-12-21  9:30 ` Markus Elfring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=954c5d70-742f-7b0e-57ad-ea967e93be89@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=Markus.Elfring@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).