Re: [PATCH v8 02/10] lib: kstrtox: add kstrntoull() helper

[Rodrigo Alencar]

On 26/03/20 01:50PM, Andy Shevchenko wrote:
> On Fri, Mar 20, 2026 at 11:16:32AM +0000, Rodrigo Alencar wrote:
> > On 26/03/04 10:02AM, Rodrigo Alencar wrote:
> > > On 26/03/03 02:16PM, Rodrigo Alencar wrote:
> > > > On 26/03/03 03:49PM, Andy Shevchenko wrote:
> > > > > On Tue, Mar 03, 2026 at 01:27:07PM +0000, Rodrigo Alencar via B4 Relay wrote:
> > > > > 
> > > > > > Add kstrntoull() function, which converts a string to an ULL with a max
> > > > > > character limit. The function is an alternative integer parsing function
> > > > > > that does not require a null-terminated string. It becomes a better option
> > > > > 
> > > > > null -->  NUL
> > > > > 
> > > > > > over simple_strtoull() or kstrtoull() when parsing integers from a buffer
> > > > > > with custom delimiters without having to create temporary copies.
> > > > > > The function is consumed inside the implementation _kstrtoull(),
> > > > > > promoting reuse.
> > > > > 
> > > > > But this will not properly convert 0000000000000000000000000000000000000000100,
> > > > > for example, if the max_chars say set to 20.
> > > > 
> > > > Why would I want that? truncation will happen in the case and the value will
> > > > be zero. max_chars can be zet to INT_MAX/SIZE_MAX if you want to get 100.
> > > > 
> > > > > Also kstrto*() have a common idea behind to consume the only \n and allowed
> > > > > digits. This (naming) doesn't fit into the kstrto*() category.
> > > > 
> > > > mmm ok, but include/linux/kstrtox.h is the right place for this? how about just
> > > > strntoull()? I feel like a safe_ prefix does not make much sense if it is
> > > > only to differentiate from simple_strto*(), which should have been safe at
> > > > the first place.
> > > 
> > > Also kstrntoull() does not really match kstrto*(), as the 'n' is often used
> > > to indicate a stop condition on amount of characters, which would not need
> > > to require any termination character at all.
> > > The 'k' prefix was add to 'strntoull', mostly because the function is being
> > > added to the include/linux/kstrtox.h file. Other names I could think off:
> > > - bounded_strtoull()
> > > - bstrtoull() - 'b' for bounded
> > > - bstrntoull()
> > > - strtoull_bounded()
> > > - strtoull_limit()
> > > - safe_strntoull() - emphasizes overflow safety over simple_strtoull()
> > > 
> > > Extras considerations:
> > > - Single-letter prefixes (bstrntoull, lstrntoull, etc.) are too cryptic
> > > for a public API
> > > - safe_ prefix is subjective and doesn't describe the actual behavior
> > > 
> > > kstrntoull() is still my first candidate, other than that it would be
> > > bounded_strtoull().
> > 
> > could you provide more feedback here? Thanks!
> 
> I don't know what new I can add here.
> 
> My suggestion was (and still is) to have something in *_strtoull() family
> with additional checks added, but no limitations on the input string (i.e.
> no max_chars).  If you look at the printf() code the max_chars was added
> solely for scanf() and has no use otherwise (yes, I know about and aware
> of initramfs case).

but is it include/linux/kstrtox.h the right place for this?
*_strtoull familly... then can we just expose simple_strntoull(), which is
private to lib/vsprintf.c, by changing its prototype to expose a error return?
In my case the limitation on the input string is useful for the truncation of
decimal places when parsing the fixed point value. It would avoid a 64-bit
division.

-- 
Kind regards,

Rodrigo Alencar