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?
