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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] kstrtoudec64() incorrectly returns -EINVAL for strings with a decimal point when scale is 0, violating the documented truncation behavior.
- [Medium] kstrtoudec64() incorrectly returns -EINVAL for valid numbers that end in a decimal point (e.g., "123.").
--

commit 4ece498f1f16417e4dd8a8ebdad47a15b89527ef
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>

lib: kstrtox: add kstrtoudec64() and kstrtodec64()

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.

> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
> index 97be2a39f5371..da7b5f83a3c59 100644
> --- a/lib/kstrtox.c
> +++ b/lib/kstrtox.c

[ ... ]

> @@ -392,6 +393,112 @@ int kstrtobool(const char *s, bool *res)
>  }
>  EXPORT_SYMBOL(kstrtobool);
>  
> +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) {

Does this cause an issue when parsing a string like "123.45" with a scale
of 0?

Since scale is 0, this condition is false, leaving the pointer at the
decimal point. The parser will then fall through to the trailing character
check:

    if (*s)
        return -EINVAL;

and fail the conversion entirely. Should this truncate the fractional part
instead, as described in the documentation?

> +		s++; /* skip decimal point */
> +		rv = _parse_integer_limit(s, 10, &_frac, scale);
> +		if (rv & KSTRTOX_OVERFLOW)
> +			return -ERANGE;
> +		if (rv == 0)
> +			return -EINVAL;

Is it possible for valid numbers ending in a decimal point (like "123.")
to be rejected here?

If the string has a decimal point but no trailing digits, rv will be 0.
While this correctly catches invalid strings consisting solely of ".", it
appears it will also incorrectly fail strings where the integer portion was
already successfully parsed.

> +		s += rv;
> +		if (rv < scale)
> +			_frac *= int_pow(10, scale - rv);
> +		while (isdigit(*s)) /* truncate */
> +			s++;
> +	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260510-adf41513-iio-driver-v12-0-34af2ed2779f@analog.com?part=2