RE: + minmax-add-umina-b-and-umaxa-b.patch added to mm-nonmm-unstable branch

[David Laight]

From: Alexey Dobriyan
> Sent: 28 September 2023 09:39
> 
> On Wed, Sep 27, 2023 at 09:00:37PM +0100, Matthew Wilcox wrote:
> > On Wed, Sep 27, 2023 at 10:21:41PM +0300, Alexey Dobriyan wrote:
> > > On Wed, Sep 27, 2023 at 10:30:33AM -0700, Andrew Morton wrote:
> > > > +#define umin(x, y)	\
> > > > +	__careful_cmp((x) + 0u + 0ul + 0ull, (y) + 0u + 0ul + 0ull, <)
> > >
> > > kmin() and kmax() are (of course!) much better names.
> >
> > it's unsigned, not user.

Linus suggested umin() as being much shorter than the min_unsigned()
I'd originally used.

> Yes, but the same idea applies to signed types:

The kernel pretty much never wants a cast to convert a large
unsigned value to a negative signed one.
If the types mismatch both values are normally non-negative
so doing an unsigned compare is right.
If you do need to treat 0u - 1 as a signed value then adding
an explicit cast is probably a good idea!

> min, max require identical types
> min_t force type
> kmin, kmax are relaxed min/max versions if signednesses match.

The 'identical types' case is pointless, and the 'force type'
often buggy.

The only reason for any type-check is to stop 'integer promotion'
converting a negative value to a very large unsigned one.
And even that isn't why the typecheck was added to min().
(That is, there is no indication that it ever caused a bug.)

	David

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