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

[Rodrigo Alencar]

On 26/04/25 11:33PM, David Laight wrote:
> On Sat, 25 Apr 2026 16:40:06 +0100
> Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> 
> > On Fri, 17 Apr 2026 09:36:20 +0100
> > Rodrigo Alencar <455.rodrigo.alencar@xxxxxxxxx> 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.    

...

> > > 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.

>From Andy's message "We still have several weeks time", I thought we would have
time to discuss this e-notation thing, but that's just a nice-to-have indeed.
It fits well in the decimal context, as it is widely used and works in powers of 10!

> 
> 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.

It may be a compact parsing but aside from bugs or typos, there is a readability
tradeoff. For the context, yes, it would be better to accumulate interger and
fractional parts to the same variable, rather than separate ones.
_parse_integer_limit() would have to allow for a custom init value, so we could
just skip the decimal point and resume. The proposed implementation reuses tested
infrastructure and follows kstrto* conventions. I suppose the most important thing
to review here is the new interface with its function prototypes.

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

I agree, I tried something like this with the kstrntoull() approach.

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

Agreed.

-- 
Kind regards,

Rodrigo Alencar