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

[David Laight <david.laight.linux@gmail.com>]

On Sat, 25 Apr 2026 16:40:06 +0100
Jonathan Cameron <jic23@kernel.org> wrote:

> On Fri, 17 Apr 2026 09:36:20 +0100
> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> 
> > On 26/04/15 10:51AM, Rodrigo Alencar wrote:  
> > > Add helpers that parses decimal numbers into 64-bit number, i.e., decimal
> > > point numbers with pre-defined scale are parsed into a 64-bit value (fixed
> > > precision). After the decimal point, digits beyond the specified scale
> > > are ignored.    
> > 
> > ...
> >   
> > > +static int _kstrtoudec64(const char *s, unsigned int scale, u64 *res)
> > > +{
> > > +	u64 _res = 0, _frac = 0;
> > > +	unsigned int rv;
> > > +
> > > +	if (scale > 19) /* log10(2^64) = 19.26 */
> > > +		return -EINVAL;
> > > +
> > > +	if (*s != '.') {
> > > +		rv = _parse_integer(s, 10, &_res);
> > > +		if (rv & KSTRTOX_OVERFLOW)
> > > +			return -ERANGE;
> > > +		if (rv == 0)
> > > +			return -EINVAL;
> > > +		s += rv;
> > > +	}
> > > +
> > > +	if (*s == '.' && scale) {
> > > +		s++; /* skip decimal point */
> > > +		rv = _parse_integer_limit(s, 10, &_frac, scale);
> > > +		if (rv & KSTRTOX_OVERFLOW)
> > > +			return -ERANGE;
> > > +		if (rv == 0)
> > > +			return -EINVAL;
> > > +		s += rv;
> > > +		if (rv < scale)
> > > +			_frac *= int_pow(10, scale - rv);
> > > +		while (isdigit(*s)) /* truncate */
> > > +			s++;
> > > +	}
> > > +
> > > +	if (*s == '\n')
> > > +		s++;
> > > +	if (*s)
> > > +		return -EINVAL;
> > > +
> > > +	if (check_mul_overflow(_res, int_pow(10, scale), &_res) ||
> > > +	    check_add_overflow(_res, _frac, &_res))
> > > +		return -ERANGE;
> > > +
> > > +	*res = _res;
> > > +	return 0;
> > > +}    
> > 
> > I have an alternative (slightly more complex) implementation of this function
> > that handles E notation. I find this particularly handy when writting big
> > values like 25 GHz when the ABI is defined in Hz, so instead of writing
> > 25000000000, one can just use 25e9, or 2.5e10. I found that my python code
> > was printing big floating point values or really small ones using E notation
> > and that was giving me -EINVAL, so I had to adjust formatting when generating
> > the string input to the file. No big deal, and we would not need this here,
> > but if maintainers find this useful I could add it into a v11 of this series.
> >   
> 
> I'd rather we didn't slow this one down. However I'm waiting on some tags
> on this patch from folk who are more familiar with these parsers than
> I am.  Given discussion, Andy or David Laight perhaps?
> +CC David - please make sure to include folk who have been active
> in discussion of earlier versions to decrease chance they miss the new
> one.

I can't help feeling this code would be smaller if it didn't try to use
the existing conversion functions.
Something like:
	u64 r = 0;
	unsigned int n = ~0;
	while (*s == ' ' || *s == '\n')
		s++;
	for (;;) {
		unsigned int dig = *s++ - '0';
		if (dig <= 9) {
			if (!n)
				continue;
			n--;
			r = r * 10 + dig;
			continue;
		}
		switch (s[-1]) {
		case '.':
			if (n <= scale)
				return -EINVAL;
			n = scale;
			continue;
		case '\n':
			if (*s)
				return -EINVAL;
			break;
		case 0:
			break;
		default:
			return -EIVAL;
		}
		break;
	}
	if (n > scale)
		n = scale;
	while (n--)
		r *= 10;
	*res = r;
	return 0;
}

That is missing the overflow detect for the multiply and add.
While check_add_overflow() hopefully looks at the carry flag (on non-mips
style cpu), I don't know how the 'mul' variant works - it might be horrid.
A bound check against ~0ull/10 might generate better code.

But I really prefer functions that return the terminating character to
the caller - they are more useful for parsing compound parameters.

	David

> 
> Maybe start a discussion about whether adding e notation as a separate
> thread after this has merged?
> 
> Jonathan
> 
>