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

[Andy Shevchenko]

On Sun, Apr 26, 2026 at 09:02:26AM +0100, Rodrigo Alencar wrote:
> 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:  

...

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

My main concern is to have one source of implementation.

Yes, we can have specific parser for the specific need in the certain subsystem,
but as I already said (and maybe not once) the problem is that if any bugs or
features is desired it may diverse for the 2+ implementations of the same, putting
bug spreading and double effort.

Having e-notation supported is fine, but can we do it separately?

> > I can't help feeling this code would be smaller if it didn't try to use
> > the existing conversion functions.
> > Something like:

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

With the wrong naming. kstrn* is oxymoron. Semantically the kstrto* are about
strict input checks, including overflow.

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

Yep, sounds like an additional feature that may be added later on.

-- 
With Best Regards,
Andy Shevchenko