On Tue, 2026-02-03 at 09:26 +0000, Rodrigo Alencar wrote:

On 26/02/02 09:57AM, Nuno Sá wrote:

quoted

On Fri, 2026-01-30 at 10:06 +0000, Rodrigo Alencar via B4 Relay wrote:

quoted

From: Rodrigo Alencar <rodrigo.alencar@analog.com>

Add iio_str_to_fixpoint64() function that leverages simple_strtoull()
to parse numbers from a string.
A helper function __iio_str_to_fixpoint64() replaces
__iio_str_to_fixpoint() implementation, extending its usage for
64-bit fixed-point parsing.

...

quoted

quoted

 /**
  * __iio_str_to_fixpoint() - Parse a fixed-point number from a string
  * @str: The string to parse

@@ -895,63 +1026,43 @@ static ssize_t iio_read_channel_info_avail(struct device *dev,

 static int __iio_str_to_fixpoint(const char *str, int fract_mult,
 				 int *integer, int *fract, bool scale_db)
 {
-	int i = 0, f = 0;
-	bool integer_part = true, negative = false;
+	s64 integer64, fract64;
+	int ret;
 
-	if (fract_mult == 0) {
-		*fract = 0;
+	ret = __iio_str_to_fixpoint64(str, fract_mult, &integer64, &fract64,
+				      scale_db);
+	if (ret)
+		return ret;

I know it feels tempting to do the above while adding the 64bit variant. But isn't the
overflow safety also an issue on the 32bit variant? IMO, we should first have a patch
adding the overflow safety with a Fixes tag and then add 64bit support.

I think handling 64-bit support after taclking the overflow issue
would require changes on top of previous ones, which might get a messy
commit history, no? Mostly because the 64-bit variant of the function
is being used inside the 32-bit one. Also, the added auxiliary function
that implements the overflow check parses u64, which allowed for the
removal of the while loop in the __iio_str_to_fixpoint() implementation.

Typically we do fixes before because we might want to backport them and we just want to backport the
fix (so not the 64bit support). But we never really had any known issues with the current API
(AFAIK) so it might be ok as-is. Will defer to Jonathan.

- Nuno Sá

before this assignment.