[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <737627fd-b68b-4c9d-8700-f0e0d6d9cec8@moroto.mountain>
Date: Fri, 12 Jan 2024 15:49:59 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: David Laight <David.Laight@...lab.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
'Andy Shevchenko' <andriy.shevchenko@...ux.intel.com>,
'Andrew Morton' <akpm@...ux-foundation.org>,
"'Matthew Wilcox (Oracle)'" <willy@...radead.org>,
'Christoph Hellwig' <hch@...radead.org>,
"'Jason A. Donenfeld'" <Jason@...c4.com>
Subject: Re: [PATCH next v4 1/5] minmax: Add umin(a, b) and umax(a, b)
On Mon, Sep 18, 2023 at 08:16:30AM +0000, David Laight wrote:
> +/**
> + * umin - return minimum of two non-negative values
> + * Signed types are zero extended to match a larger unsigned type.
> + * @x: first value
> + * @y: second value
> + */
> +#define umin(x, y) \
> + __careful_cmp((x) + 0u + 0ul + 0ull, (y) + 0u + 0ul + 0ull, <)
Why do we match "a larger unsigned type" instead of ULL_MAX? Presumably
it helps performance somehow... I agree that it's probably fine but I
would be more comfortable if it skipped UINT_MAX and jumped directly to
ULONG_MAX. These days 4 gigs is small potatoes. The vmalloc() function
can allocate 4G so we've had integer overflow bugs with this before.
regards,
dan carpenter
Powered by blists - more mailing lists