kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Raka Gunarto <rakagunarto@gmail.com>
Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>,
	kernelnewbies <Kernelnewbies@kernelnewbies.org>
Subject: Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis
Date: Fri, 25 Jul 2025 15:56:11 +0200	[thread overview]
Message-ID: <2025072517-prenatal-vendetta-a9aa@gregkh> (raw)
In-Reply-To: <CACUOwm+5fyqcJy18sWfSXCpBq7wSesuaLMbB9Oy6xhL8Y9DWTQ@mail.gmail.com>

On Fri, Jul 25, 2025 at 01:42:14PM +0100, Raka Gunarto wrote:
> On Fri, Jul 25, 2025 at 1:19 PM Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
> > Interesting idea. Other than silencing clang analyzer warning, what is exactly the advantage of using such macro?
> 
> Well there are three main advantages that I saw:
> - Clarity to readers that the pointer is guaranteed to be non-null,
> and that a check is redundant (because performance critical context,
> etc.)

We already assume this in loads of places today, there's no need to
explicitly mark it as such everywhere, as that would litter almost every
single function in the kernel :(

> - Future patches that decide to use this macro can be a signal to
> reviewers to actually check correctness that a pointer is indeed
> invariably non-null

That's up to the caller, not a reviewer, to keep straight.

> - Make static analysis more useful by documenting when a certain false
> positive is actually false

Fix the tool, not the kernel code, when the tool is broken.  It's not
Linux's job to paste over broken external things.

> I also wondered if it could reduce the possibility and volume of AI
> generated patches from just running analyzers on the kernel to reduce
> noise.

Have you seen any such reports yet?  The ones I've seen are not due to
this type of thing at all, they are much more "real looking" yet fall
apart when a person actually reads the code.

Here's one such "fake report" example if you enjoy reading this type of
thing:
	https://lore.kernel.org/r/tencent_21B82DB792FE0049B6EF5ECD81285669C908@qq.com

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  parent reply	other threads:[~2025-07-25 14:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250723140129.276874-1-rakagunarto@gmail.com>
2025-07-25 10:34 ` Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis Raka Gunarto
2025-07-25 12:06   ` Greg KH
2025-07-25 12:18   ` Mulyadi Santosa
2025-07-25 12:42     ` Raka Gunarto
2025-07-25 13:28       ` Siddh Raman Pant
2025-07-25 13:56       ` Greg KH [this message]
2025-07-25 15:07         ` Raka Gunarto
2025-07-25 17:04           ` Tom Mitchell

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=2025072517-prenatal-vendetta-a9aa@gregkh \
    --to=greg@kroah.com \
    --cc=Kernelnewbies@kernelnewbies.org \
    --cc=mulyadi.santosa@gmail.com \
    --cc=rakagunarto@gmail.com \
    /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).