Re: [PATCH v4 3/4] cleanup: Annotate guard constructors with __nonnull()

[Dmitry Ilvokhin <d@ilvokhin.com>]

On Tue, May 26, 2026 at 07:54:16PM +0200, Miguel Ojeda wrote:
> On Tue, May 26, 2026 at 5:13 PM Dmitry Ilvokhin <d@ilvokhin.com> wrote:
> >
> > They usually don't collide, except for User Mode Linux builds, which
> > include both kernel and userspace headers.
> 
> :(
> 
> What about other similar names? i.e. a variation of your option 2,
> e.g. just `nonnull` (we also have others like that, i.e. no
> underscore, e.g. `noinline`), or `___nonnull` (triple underscore, but
> may be confusing), or a suffix/prefix letter, e.g. `__knonnull` (for
> kernel nonnull)...
> 
> i.e. it would be nice to have a "standard" spelling for ourselves, and
> also replace the existing `__attribute__((nonnull))`s we have
> elsewhere in the tree.

Yes, a different name might work as well. The main question is which
name to pick.

Plain nonnull() is a bit dangerous. It might collide with existing
identifiers (now or in the future) and is not great for a kernel-wide
macro. I think we got away with plain noinline, because it was there
forever. There are also at least 24 nonnull attribute usages in the
kernel that need to be converted atomically. This can be done, but it
increases the scope of the patchset, which I'd rather avoid.

___nonnull() with triple underscore might be a bit confusing, I agree.

__knonnull() might work. I like __nonnull_args() better: it gives the
reader a hint about the semantics, while __knonnull() is just a
collision-avoidance trick without conveying any additional meaning. That
being said, I can totally do __knonnull().

> 
> Cheers,
> Miguel