Re: [PATCH v2 1/2] minmax: Add in_range_inclusive() for inclusive range checks

[Guru Das Srinagesh <linux@gurudas.dev>]

On Mon, Aug 17, 2026 at 11:06:35AM +0300, Andy Shevchenko wrote:
> On Sun, Aug 16, 2026 at 12:26:20PM -0700, Guru Das Srinagesh wrote:
> > in_range(val, start, len) takes a start and a length, i.e. a half-open
> > range. Callers that instead have an inclusive [start, end] bound have
> > no ready helper to reach for and either hand-roll the comparison or
> > convert it to in_range()'s (start, len) form themselves.
> > 
> > Add in_range_inclusive(val, start, end) as a direct comparison rather
> > than a wrapper around in_range(): computing len as end - start + 1 and
> > forwarding it to in_range() subverts in_range()'s 32-bit/64-bit dispatch
> > for sub-32-bit types via integer promotion, and overflows to 0 when @end
> > is the type's maximum value, silently rejecting every input instead of
> > accepting all of them.
> > 
> > val, start and end are each assigned to a __UNIQUE_ID()-generated
> > temporary before use, matching the __cmp_once()/__cmp_once_unique()
> > pattern: each argument is evaluated exactly once, and the temporary
> > can't be shadowed by a caller's own same-named local variable.
> 
> No new code to lib/ without test cases.
> NAK (until the test cases are not provided).

Done, added KUnit test cases to v3.

> > +/**
> > + * in_range_inclusive - Determine if a value lies within an inclusive range.
> > + * @val: Value to test.
> > + * @start: First value in range.
> > + * @end: Last value in range.
> > + *
> > + * @val, @start and @end are each evaluated exactly once.
> 
> This misses the return section (yes, this is not obvious, but needs to add it)

Done, added return section to v3 kernel-doc.

> > + */
> > +#define in_range_inclusive(val, start, end)				\
> > +	__in_range_inclusive(val, start, end, __UNIQUE_ID(val_),	\
> > +			     __UNIQUE_ID(start_), __UNIQUE_ID(end_))
> 
> Do you know what __UNIQUE_ID() does and how it will affect the preprocessed
> size? It may or may not be needed depending on the (current) use cases.

Sorry, __UNIQUE_ID() has been dropped in v3 as v3 follows in_range() more closely and
does not need any temporary variables.