[RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis

[Tom Mitchell]

Interesting...
Missing in this is the static analysis tool, name and version.
There are many.

At the source level one might start with an assert().   Assuming nonnull
implies null is legal and would  be handled correctly if not optimal.

Interesting
..

Sent-mobile
T o m   M i t c h e l l

On Fri, Jul 25, 2025, 8:24 AM Raka Gunarto <rakagunarto at gmail.com> wrote:

> On Fri, Jul 25, 2025 at 2:56 PM Greg KH <greg at kroah.com> wrote:
> > 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 :(
>
> I suppose based on this alone I should rethink the usefulness of this
> patch,
> especially if the next step would be to blast apply it everywhere.
>
> Although I was more thinking of future use, and clarity to future readers
> on why a pointer couldn't be null.
>
> I'll respond to the other points but I'll have a rethink on whether or not
> this is an actually useful addition, or whether or not we could deal with
> static analyser false positives in a better way.
>
> > Fix the tool, not the kernel code, when the tool is broken.  It's not
> > Linux's job to paste over broken external things.
>
> Understood, however I recognise static analysis is complex and there
> are many non obvious cases of why something is a false positive.
> My rationale was that adding this macro and a comment to document
> for example, a non obvious non-null pointer, could be useful to
> readers.
>
> On Fri, Jul 25, 2025 at 2:29 PM Siddh Raman Pant <sanganaka at siddh.me>
> wrote:
> > Assumption isn't a guarantee.
> > Compiler optimises it away usually.
>
> Yes, but my point was it is guaranteed in some cases, just not
> obvious to the static analyzer and since the compiler /
> static analyzer use similar techniques to detect certain
> conditions, the compiler won't optimise a redundant check
> away either.
>
> > That can pretty easily change in future.
>
> Isn't it more dangerous to have a non obvious assumption
> be in the blast radius of a change that makes that
> assumption invalid, rather than making it obvious in some
> way?
>
> > Is your case really a false positive?
>
> From my very limited understanding of the slab allocator,
> I think it is a false positive because it is only called
> on valid slabs (initial slab must be non-null and
> it just traverses the list).
>
> Thank you all for the feedback, it was very insightful
> for me as an aspiring contributor!
>
> Raka
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20250725/ac52cde1/attachment.html>