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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

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);
	if (ret)
		return ret; // overflow!

	if (end - start > $YOUR_LIMIT)
		return -EINVAL; // bad input

	...process result...

...

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?

-- 
With Best Regards,
Andy Shevchenko