Don't test bitmap_set(bitmap, start, 0) as it's useless, most probably
a sign of error in real code, and makes CONFIG_DEBUG_BITMAP barking.
Signed-off-by: Yury Norov <[email protected]>
---
lib/test_bitmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 98754ff9fe68..2a70393ac011 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -622,7 +622,7 @@ static void noinline __init test_mem_optimisations(void)
unsigned int start, nbits;
for (start = 0; start < 1024; start += 8) {
- for (nbits = 0; nbits < 1024 - start; nbits += 8) {
+ for (nbits = 1; nbits < 1024 - start; nbits += 8) {
memset(bmap1, 0x5a, sizeof(bmap1));
memset(bmap2, 0x5a, sizeof(bmap2));
--
2.34.1
On Mon, Jul 18, 2022 at 12:28:31PM -0700, Yury Norov wrote:
> Don't test bitmap_set(bitmap, start, 0) as it's useless, most probably
> a sign of error in real code, and makes CONFIG_DEBUG_BITMAP barking.
No, the test of not useful and sign of an error is a good thing to test!
Test cases may be positive, may be negative. Code shouldn't fail badly because
of that.
I tend to give a NAK here.
--
With Best Regards,
Andy Shevchenko
On 18/07/2022 21.28, Yury Norov wrote:
> Don't test bitmap_set(bitmap, start, 0) as it's useless, most probably
> a sign of error in real code,
No it's not. The nbits can easily be the result of some computation that
ended up resulting in 0 being the right number to copy (or set, or
whatnot), and it's not unreasonable to _not_ check in the caller for
that special case, but rather rely on bitmap_set() to behave sanely - it
has perfectly well-defined semantics to "set 0 bits starting at @start".
The same way that memset() and memcpy() and memcmp() and countless other
functions have perfectly well-defined semantics with a length of 0, and
we don't add caller-side checks for those either.
NAK on this series.
Rasmus