Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype

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

On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:

...

> > +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> > +					     unsigned int base, size_t max_chars,
> > +					     unsigned long long *res);
> 
> Sigh, naming is hard. I personally find it a bit confusing that the
> name is too similar to the unsafe API.
> 
> IMHO, the semantic of the new API is closer to kstrtoull().
> It just limits the size, so I would call it kstrntoull().

It's not. kstrto*() quite strict about the input, this one is actually relaxed
variant, so I wouldn't mix these two groups.

> Also I would use int as the return parameter, see below.

...

TBH, I am skeptical about this approach. My main objection is max_chars
parameter. If we want to limit the input strictly to the given number of
characters, we have to copy the string and then just use kstrto*() in a normal
way. The whole idea of that parameter is to be able to parse the fractional
part of the float number as 'iiiii.fffff', where 'i' is for integer part, and
'f' for the fractional. Since we have *endp, we may simply check that.

In case if we want to parse only, say, 6 digits and input is longer there are
a few options (in my personal preferences, the first is the better):
- consider the input invalid
- parse it as is up to the maximum and then do ceil() or floor() on top of that
- copy only necessary amount of the (sub)string and parse that.

The problem with precision is that we need to also consider floor() or ceil()
and I don't think this should be burden of the library as it's individual
preference of each of the callers (users). At least for the starter, we will
see if it's only one approach is used, we may incorporate it into the library
code.

The easiest way out is to just consider the input invalid if it overflows the
given type (s32 or s64).

But we need to have an agreement what will be the representation of the
fixed-width float numbers in the kernel? Currently IIO uses
	struct float // name is crafted for simplicity
	{
		int integer;
		int fraction;
	}

This parser wants AFAIU to have at the end of the day something like

	struct float
	{
		s64 integer;
		s64 fraction;
	}

but also wants to have the fraction part be limited in some cases to s32
or so:

	struct float
	{
		s64 integer;
		s32 fraction; // precision may be lost if input is longer
	}

Maybe we want to have kstrtof32() and kstrtof64() for these two cases?

With that we will always consider the fraction part as 32- or 64-bit,
imply floor() on the fraction for the sake of simplicity and require
it to be NUL-terminated with possible trailing '\n'.

-- 
With Best Regards,
Andy Shevchenko