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

Jonathan Cameron
2026-04-25T15:40:18Z

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.

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

Jonathan