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

[Andy Shevchenko]

On Fri, Mar 20, 2026 at 12:41:57PM +0000, Rodrigo Alencar wrote:
> On 26/03/20 02:24PM, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2026 at 12:08:41PM +0000, Rodrigo Alencar wrote:
> > > 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:

...

> > > > > 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?
> > 
> > Seems so, there simple_strto*() are declared.
> > 
> > > *_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?
> > 
> > Why do you need that? I'm lost, sorry, I don't understand this big desire of
> > having that max_chars parameter.
> > 
> > > 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.
> > 
> > How is it better than checking the returned end pointer? Just treat anything
> > that parses too many digits after dot as invalid input?
> > 
> > 	ret = ..._strtoull(..., &end, &result);
> 
> here I would want to pass max_chars as the precision of the fixed point parsing
> 
> > 	if (ret)
> > 		return ret; // overflow!
> > 
> > 	if (end - start > $YOUR_LIMIT)
> > 		return -EINVAL; // bad input
> > 
> > 	...process result...
> 
> otherwise, here I would need to check the amount of parsed characters and
> perform a 64-bit division if it goes beyond the desired precision.
> Also, having max_chars allows for more flexible usage of the parsing function.
> 
> this is the prototype of simple_strntoull() that would be thinking on expose:
> 
> int simple_strntoull(const char *startp, char **endp,
> 		     unsigned long long *res, unsigned int base,
> 		     size_t max_chars)
> 
> that would also allow to drop the existing FIXME in simple_strntoull().

That's fine, but the prototype should be rather

int simple_strntoull(const char *startp, char **endp,
		     unsigned int base, size_t max_chars, unsigned long long *res)

> > Some (stupid) thoughts loudly. IIUC even if we implement '%g' in scanf(), it
> > wont help you as you want to have more precise values. Do I get it correct?
> 
> If I am parsing 3.14159265359 with 6 decimal precision I want to stop at:
> 
> frac = 141592
> int = 3

This is different to what strto*() usually do. From my p.o.v. this is simply
an invalid input, and TBH, the parsing of this is not as trivial as flooring
the result. One might want ceiling it, and see the difference when it's about
signed value. So, if one wants lesser precision they need to set the rules,
and not the library, because there are several rules that the user may want
to adjust.

P.S.
Avoiding division in your case is copying a (sub)string and using kstrto*() on it.
I believe it's always a room for 20-30 bytes on the stack for that, and it will be
much faster than division, indeed.

-- 
With Best Regards,
Andy Shevchenko