[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28b33db24b1dbd15cd6711cd473f1c0e5f801e74.camel@perches.com>
Date: Thu, 04 Jun 2020 09:49:46 -0700
From: Joe Perches <joe@...ches.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
Rikard Falkeborn <rikard.falkeborn@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Arnd Bergmann <arnd@...db.de>, emil.l.velikov@...il.com,
Kees Cook <keescook@...omium.org>,
Linus Walleij <linus.walleij@...aro.org>,
Linux-Arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Syed Nayyar Waris <syednwaris@...il.com>,
William Breathitt Gray <vilhelm.gray@...il.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
kbuild test robot <lkp@...el.com>
Subject: Re: [PATCH] linux/bits.h: fix unsigned less than zero warnings
On Thu, 2020-06-04 at 09:41 +0300, Andy Shevchenko wrote:
> I think there is still a possibility to improve (as I mentioned there
> are test cases that are absent right now).
> What if we will have unsigned long value 0x100000001? Would it be 1
> after casting?
>
> Maybe cast to (long) or (long long) more appropriate?
Another good mechanism would be to compile-time check the use
of constants in BITS and BITS_ULL and verify that:
range of BITS is:
>= 0 && < (BITS_PER_BYTE * sizeof(unsigned int))
range of BITS_ULL is:
>= 0 && < (BITS_PER_BYTE * sizeof(unsigned long long))
There would be duplication similar to the GENMASK_INPUT_CHECK
macros.
Powered by blists - more mailing lists