RE: [PATCH v4 07/13] minmax: Introduce {min,max}_array()

[David Laight]

From: Herve Codina <herve.codina@xxxxxxxxxxx>
> Sent: 16 June 2023 12:49
> 
> Hi David,
> 
> On Fri, 16 Jun 2023 09:08:22 +0000
> David Laight <David.Laight@xxxxxxxxxx> wrote:
> 
> ...
> 
> >
> > Just define two variables typeof(__array[0] + 0) one for an element
> > and one for the limit.
> > The just test (eg):
> > 	if (limit > item) limit = item;
> > finally cast the limit back to the original type.
> > The promotions of char/short to signed int won't matter.
> > There is no need for all the type-checking in min/max.
> >
> > Indeed, if min_t(type, a, b) is in anyway sane it should
> > expand to:
> > 	type _a = a, _b = b;
> > 	_a < _b ? _a : _b
> > without any of the checks that min() does.
> 
> I finally move to use _Generic() in order to "unconstify" and avoid the
> integer promotion. With this done, no extra cast is needed and min()/max()
> are usable.
> 
> The patch is available in the v5 series.
>   https://lore.kernel.org/linux-kernel/20230615152631.224529-8-herve.codina@xxxxxxxxxxx/
> 
> Do you think the code present in the v5 series should be changed ?
> If so, can you give me your feedback on the v5 series ?

It seems horribly over-complicated just to get around the perverse
over-strong type checking that min/max do just to avoid sign
extension issues.

Maybe I ought to try getting a patch accepted that just checks
  is_signed_type(typeof(x)) == is_signed_type(typeof(y))
instead of
  typeof(x) == typeof(y)
Then worry about the valid signed v unsigned cases.

Indeed, since the array index can be assumed not to have side
effects you could use __cmp(x, y, op) directly.

No one has pointed out that __element should be __bound.

	David

	

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)