Re: [PATCH v12 02/11] lib: kstrtox: add kstrtoudec64() and kstrtodec64()

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

On Tue, May 12, 2026 at 05:18:14PM +0100, David Laight wrote:
> On Tue, 12 May 2026 18:21:44 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

...

> > > I think we are going in circles here and we could look at the code instead:
> > > - integer parsing with _parse_integer()
> > >         - overflow check and validation of the return value
> > > - fractional parsing with _parse_integer_limit()
> > >         - overflow check and validation of the return value  
> > 
> > No, this is not fully true. That's what my whole point is about. The
> > max_chars parameter limits the input check, then it skips an arbitrary
> > number of digits and only *then* it checks for \n and \0. What will be
> > the result of the
> > 0.00000000000000000000000000000000423 in your case? Whatever scale you
> > gave it will return 0 without checking on how many digits were
> > supplied. All the same for 0.9999999999999999999999999999999000423. My
> > point is that we should limit this by 19 digits.
> 
> Don't forget about 000000000.123

And how is it special? We don't care about the integer part as we use
parse_integer() which does check for overflow.

> And that you also need to worry about leading spaces affecting the length.

Leading spaces is a bad input.

> To me, the easy way to parse it is to know how many digits are valid
> after the '.' and just carry on parsing digits after a '.' until the
> limit is hit.
> If you really want one function, pass zero to indicate that '.' is invalid.

Would this function makes any sense to be run with scale == 0?

> > On top of that, what about -0.9(19 times) ? the fraction should be u64
> > in this case and it's fine. The sign applies to the combined value.
> > 
> > >         - extra scaling and truncation happening outside if needed.  
> > 
> > Right, but the given input may be way too long and still needs more validation.
> > 
> > > - check for input termination
> > > - combination of integer and fractional parts with check_mul_overflow() and check_add_overflow()
> 
> A lot of the time overflow can be ignored because the digit string is short.
> The check_mul_overflow() code is likely to measurably slow things down.
> (Especially on 32bit where even a compare against 2**64/10 isn't cheap.)
> 
> > > > > > Maybe I'm missing these checks already performed?
> > > > > >  
> > > > > > > > Having the test cases is a big benefit, and that part I like the most.  

-- 
With Best Regards,
Andy Shevchenko