[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210930103010.2716097-1-antti.kervinen@intel.com>
Date: Thu, 30 Sep 2021 13:30:10 +0300
From: Antti Kervinen <antti.kervinen@...el.com>
To: tklauser@...tanz.ch
Cc: Jonathan.Cameron@...wei.com, akpm@...ux-foundation.org,
andriy.shevchenko@...ux.intel.com, gregkh@...uxfoundation.org,
linux-kernel@...r.kernel.org, peterz@...radead.org,
song.bao.hua@...ilicon.com, tiantao6@...ilicon.com,
yury.norov@...il.com
Subject: Re: [PATCH] cpumask: Omit terminating null byte in cpumap_print_{list,bitmask}_to_buf
An original function, bitmap_print_to_pagebuf() in lib/bitmap.c,
returns the number of printed characters, excluding terminating null.
Commit 1fae5629, a cause of this regression, introduced new functions
to lib/bitmap.c:
- bitmap_print_to_buf()
(return value doc missing)
- bitmap_print_bitmask_to_buf()
(return value doc not explicit about terminating null, but
can be considered misleading)
- bitmap_print_list_to_buf()
(the same as above)
Unlike the original function, the return value of new functions
include the terminating null.
As this behavior is clearly opposite to the original function, and
functions that print to buffers in general, I would suggest fixing
this problem by alignign these new functions with the original one:
excluding the terminating null. And documenting this behavior
unambiguously.
The suggested change to cpumask_print_{bitmask,list}_to_buf()
functions decrements possible errors (like -ENOMEM) returned by
bitmap_print_to_buf(). This must not happen.
Powered by blists - more mailing lists