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

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).

...

> +/**
> + * 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)

> + */
> +#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.

-- 
With Best Regards,
Andy Shevchenko