ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: ksummit@lists.linux.dev, Julia Lawall <julia.lawall@inria.fr>
Subject: Re: Potential static analysis ideas
Date: Mon, 26 Jul 2021 08:50:39 -0700	[thread overview]
Message-ID: <20210726155039.GR4397@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20210723191023.GG25548@kadam>

On Fri, Jul 23, 2021 at 10:10:23PM +0300, Dan Carpenter wrote:
> Rust has many good static analysis features but if we wanted we could
> implement a number of stricter rules in C.  With Smatch I have tried to
> focus on exclusively on finding bugs because everyone can agree that
> bugs are bad.  But if some subsystems wanted to implement stricter rules
> just as a hardenning measure then that's a doable thing.
> 
> For example, I've tried a bunch of approaches to warning about when the
> user can trigger an integer overflow.  The challenge is that most
> integer overflows are harmless and do not cause a real life bug.

I would not want overflow checks for unsigned integers, but it might
be helpful for signed integers.  But yes, most of us rely on fwrapv,
so that kernelwide checks for signed integer overflow will be quite noisy.

							Thanx, Paul

  parent reply	other threads:[~2021-07-26 15:50 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 19:10 Potential static analysis ideas Dan Carpenter
2021-07-24 13:33 ` Geert Uytterhoeven
2021-07-24 13:40   ` Julia Lawall
2021-07-24 14:08   ` Arnd Bergmann
2021-07-24 23:18   ` Laurent Pinchart
2021-07-24 23:45     ` NeilBrown
2021-07-26  7:25       ` Arnd Bergmann
2021-07-26  7:53         ` Geert Uytterhoeven
2021-07-26  8:20           ` Arnd Bergmann
2021-07-26  8:39             ` Geert Uytterhoeven
2021-07-26  8:52               ` Arnd Bergmann
2021-07-26  9:11                 ` Geert Uytterhoeven
2021-07-26  8:55             ` Julia Lawall
2021-07-26  9:08               ` Hannes Reinecke
2021-07-26  9:16                 ` Geert Uytterhoeven
2021-07-26  9:28                   ` Julia Lawall
2021-07-26  9:35                     ` Hannes Reinecke
2021-07-26 10:03                       ` Julia Lawall
2021-07-26 17:54                   ` James Bottomley
2021-07-26 18:16                     ` Linus Torvalds
2021-07-26 21:53                       ` NeilBrown
2021-07-26 18:31                     ` Laurent Pinchart
2021-07-26  9:17                 ` Dan Carpenter
2021-07-26  9:13             ` Dan Carpenter
2021-07-26 21:43         ` NeilBrown
2021-07-26  7:05   ` Dan Carpenter
2021-07-26 15:50 ` Paul E. McKenney [this message]
2021-07-27  9:38   ` Dan Carpenter
2021-07-27  9:50     ` Geert Uytterhoeven
2021-07-27 16:06     ` Paul E. McKenney

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=20210726155039.GR4397@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=dan.carpenter@oracle.com \
    --cc=julia.lawall@inria.fr \
    --cc=ksummit@lists.linux.dev \
    /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).