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

[Tom Mitchell <niftylinkern@xxxxxxxxxxxx>]

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@xxxxxxxxx> wrote:

On Fri, Jul 25, 2025 at 2:56 PM Greg KH <greg@xxxxxxxxx> 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@xxxxxxxx> 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?