Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1160167ybp; Wed, 9 Oct 2019 09:38:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqy28xeYLkFsDUAvJuQ8jhfnTONmDHeih1lm7Z7hulEFbfacVyNblXym5IsYzrTvy+CS9mz0 X-Received: by 2002:aa7:cb5a:: with SMTP id w26mr3924370edt.188.1570639128446; Wed, 09 Oct 2019 09:38:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570639128; cv=none; d=google.com; s=arc-20160816; b=V3l5vI77h622FfCiwsY5q4xmIE6mBWX41Aam20MhSdC/xymYuKg4p+SV9fIUKvVpbZ bffpp3U8lCmAHMBoMkKLhUwcSaQPe10h19TF9BjR3gTvHLKFw6C0iXZ98H3Ez/golWOt T2AA1e4+ZYIvAjVDKDoOp857jNCkjtHNK4M8fapWjAEE5LSodVSf7ByfSsojsVS4Orho WTvV9IE1DHRquY/u6fiKbF8yo1b/m8ZCkDKSzhBHpo7B0sqNO2o0m7Hl7UU0v4VSmRg5 fiyam2Ha9PPHpsMPIHuuKD5R0kTWlP3UOoXif/sCg7ugEXSzSbGdrmk6c58IyG/lrJ3j jhug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=cm6xEVsGwYj1bOXieZbPy4ZDP5MnNDK2qjTeg6wz+bE=; b=UslFAFK+Sci/p9XRaTASPXNmSbq14Cv1Iv4msEotQy1EB+DTIC/JPL1LEqQPK9bs8j DVekhE+If++zC+BoJwCVupMINT+SPBGMxR/FLxY37Fu2lntKL9cQewg8o6mguI2oi5Li jfnFzn18QCbdtW6iCVERD/mqwelOaaehZbAPril6zb67mg2WqZYuwUJJO8w0YdVY6/Mg eiHrfj8TvmHWCERQ3OKmRETzwHD9WD4jJyMwcjchHWccXvhxQV8A5ouLp2wjAXzn457M RGB9OQRuStkbDO5hBD+j4CfxbOgq++bdy0ovkE/0QUhGU1LWrow3vgYGmZyGjabRoggE QuUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=AYnKIC6J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cw1si1447932ejb.117.2019.10.09.09.38.24; Wed, 09 Oct 2019 09:38:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=AYnKIC6J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731739AbfJIQiB (ORCPT + 99 others); Wed, 9 Oct 2019 12:38:01 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:37583 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730674AbfJIQiB (ORCPT ); Wed, 9 Oct 2019 12:38:01 -0400 Received: by mail-pg1-f195.google.com with SMTP id p1so1754302pgi.4 for ; Wed, 09 Oct 2019 09:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cm6xEVsGwYj1bOXieZbPy4ZDP5MnNDK2qjTeg6wz+bE=; b=AYnKIC6JYHYX+sRMiD66kmxh0HDrEQyjtJreNsMiRGvD5zRNXvpo0NYn/dYwGvpqjx BLXXdFyvPUmR3WONaA4zuEKsF3MNz8ISYlA4MtwRPTP9i48G/xBxottH/Qb1q9M63bjv GVSrWArmpiaw4n/jK+3QxEXi9cm222bVlI2E7jd3oqkSQTXpbH817Kp37H8ZSnrsDv7z SMDCBEOc+uf8CMCGFcNlPeZGdQ1g8Q5Xw3jqXbrIR1/tC6rJCfF9rAWHn95PMmOqg2fN avrZkSVfygy5NZ8Xh9D4emZhrqZYmNx3oecZaY4YlhkazYMqam+WU2Q33JHO2JTzJwv1 USyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cm6xEVsGwYj1bOXieZbPy4ZDP5MnNDK2qjTeg6wz+bE=; b=qESMvCyUJRcDn6xm7DizF9uh6YvUbe3v8z+8oahvlxnt9e0odL+YCgGh6lb5GsFKlU wJWKrRKVLrPBhomBFrWi5T+BQlr8axZwKmwaZfgoIe/AQm5sKQTi1lnjDu4YBBgmdVdl wAw/EHxB5lMQjdZJGYOVvUMt4ZmzrDiktDopWmBmtFF+oDqfx2Qf4IIfQDklG/mPA+yp 16VD2yMzNA7SQDik/zajtMhF+qCarVamRcsUvUoJCJ4PF4/P77UtzxJEedD32vWbJO8R LsVg4sxnGgbSk5Sa/rabYV/L2HAokh3RXdlPecRxTdPdY8Aut29GsTPJaphnlL3OZTKP z1KQ== X-Gm-Message-State: APjAAAXGR3bLduj3LM6+m2N0uuTKOpnVfYHyGmpgPEayg1ErB48eODVD knFrrzKfLKrkf5noYoIBw8V7D51dqmKgSwkNggVK9w== X-Received: by 2002:aa7:8210:: with SMTP id k16mr4787726pfi.84.1570639079561; Wed, 09 Oct 2019 09:37:59 -0700 (PDT) MIME-Version: 1.0 References: <75f70e5e-9ece-d6d1-a2c5-2f3ad79b9ccb@web.de> <954c5d70-742f-7b0e-57ad-ea967e93be89@rasmusvillemoes.dk> In-Reply-To: <954c5d70-742f-7b0e-57ad-ea967e93be89@rasmusvillemoes.dk> From: Nick Desaulniers Date: Wed, 9 Oct 2019 09:37:48 -0700 Message-ID: Subject: Re: [PATCH] string.h: Mark 34 functions with __must_check To: Rasmus Villemoes Cc: Markus Elfring , kernel-janitors@vger.kernel.org, Alexander Shishkin , Andrew Morton , Andy Shevchenko , Joe Perches , Kees Cook , Steven Rostedt , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 9, 2019 at 6:26 AM Rasmus Villemoes wrote: > > On 09/10/2019 14.14, Markus Elfring wrote: > > From: Markus Elfring > > 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 =E2=80=9C__must_check=E2=80=9D in the shown fun= ction 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 Just seeing the amount of trivial errors that folks push that 0day bot spots, I don't think this would hurt. "No true Scotsman" writes C code without properly checking their return types (today), but if anything it would help cut down on silly trivial mistakes before they reach code review (assuming the code was compile tested before sent, which a lot of it is not, as per the many many many 0day bot emails I ignore because it's obvious folks didn't even try compiling their code). > consistent - strlen() is not annotated. And, for the standard C > functions, -Wall already seems to warn about an unused call: > > #include > int f(const char *s) > { > strlen(s); > return 3; > } > $ gcc -Wall -o a.o -c a.c > a.c: In function =E2=80=98f=E2=80=99: > 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 =3D kstrdup() not Which is better than nothing, IMO. > 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 --=20 Thanks, ~Nick Desaulniers