| Date | Mon, 10 Jul 2023 16:13:41 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v5 01/38] minmax: Add in_range() macro |
| |
On Mon, 10 Jul 2023 21:43:02 +0100 "Matthew Wilcox (Oracle)" <willy@infradead.org> wrote:
> Determine if a value lies within a range more efficiently (subtraction + > comparison vs two comparisons and an AND). It also has useful (under > some circumstances) behaviour if the range exceeds the maximum value of > the type. > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> > --- a/include/linux/minmax.h > +++ b/include/linux/minmax.h > @@ -158,6 +158,32 @@ > */ > #define clamp_val(val, lo, hi) clamp_t(typeof(val), val, lo, hi) > > +static inline bool in_range64(u64 val, u64 start, u64 len) > +{ > + return (val - start) < len; > +} > + > +static inline bool in_range32(u32 val, u32 start, u32 len) > +{ > + return (val - start) < len; > +} > + > +/** > + * in_range - Determine if a value lies within a range. > + * @val: Value to test. > + * @start: First value in range. > + * @len: Number of values in range. > + * > + * This is more efficient than "if (start <= val && val < (start + len))". > + * It also gives a different answer if @start + @len overflows the size of > + * the type by a sufficient amount to encompass @val. Decide for yourself > + * which behaviour you want, or prove that start + len never overflow. > + * Do not blindly replace one form with the other. > + */ > +#define in_range(val, start, len) \ > + sizeof(start) <= sizeof(u32) ? in_range32(val, start, len) : \ > + in_range64(val, start, len)
There's nothing here to prevent callers from passing a mixture of 32-bit and 64-bit values, possibly resulting in truncation of `val' or `len'.
Obviously caller is being dumb, but I think it's cost-free to check all three of the arguments for 64-bitness?
Or do a min()/max()-style check for consistently typed arguments?
|