Messages in this thread | | | From | David Laight <> | Subject | RE: + minmax-add-umina-b-and-umaxa-b.patch added to mm-nonmm-unstable branch | Date | Thu, 28 Sep 2023 08:55:17 +0000 |
| |
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)
| |