[PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Andy Shevchenko]

Currently every new wrapper on _parse_integer_limit() will need a new name
to share with users while keeping some optional arguments to be initialised
explicitly. Since there is an attempt to expand this more, I decided to
suggest this mini series to avoid namespace pollution and unneeded churn in
the future.

To expand this API more, the possible future change may be:

 unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
-                                  size_t max_chars);
+                                  size_t max_chars, $new_opt_arg);

 #define _parse_integer0(s, base, res, ...)                                              \
-        _parse_integer_limit(s, base, res, INT_MAX);
+        _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default);

 #define _parse_integer1(s, base, res, max_chars, ...)                                   \
-        _parse_integer_limit(s, base, res, max_chars);
+        _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default);

+#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...)                      \
+        _parse_integer_limit(s, base, res, max_chars, new_opt_arg);

So you got the idea. (It is roughly overloaded function in OOP.)

Andy Shevchenko (2):
  kstrtox: Make _parse_integer() take variadic arguments
  vsprintf: Convert to use _parse_integer() instead of
    _parse_integer_limit()

 lib/kstrtox.c  |  6 ------
 lib/kstrtox.h  | 12 +++++++++++-
 lib/vsprintf.c |  2 +-
 3 files changed, 12 insertions(+), 8 deletions(-)

-- 
2.50.1

[PATCH v1 1/2] kstrtox: Make _parse_integer() take variadic arguments

[Andy Shevchenko]

Instead of having different functions that just use default parameters,
combine those to use variadic arguments, so the user may call it using
the same name.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 lib/kstrtox.c | 6 ------
 lib/kstrtox.h | 9 ++++++++-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/lib/kstrtox.c b/lib/kstrtox.c
index edc4eb7c1bca..adc03e27e4a2 100644
--- a/lib/kstrtox.c
+++ b/lib/kstrtox.c
@@ -94,12 +94,6 @@ unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned lon
 	return rv | overflow;
 }
 
-noinline
-unsigned int _parse_integer(const char *s, unsigned int base, unsigned long long *p)
-{
-	return _parse_integer_limit(s, base, p, INT_MAX);
-}
-
 static int _kstrtoull(const char *s, unsigned int base, unsigned long long *res)
 {
 	unsigned long long _res;
diff --git a/lib/kstrtox.h b/lib/kstrtox.h
index 158c400ca865..6c7ca3b67429 100644
--- a/lib/kstrtox.h
+++ b/lib/kstrtox.h
@@ -2,10 +2,17 @@
 #ifndef _LIB_KSTRTOX_H
 #define _LIB_KSTRTOX_H
 
+#include <linux/args.h>
+
 #define KSTRTOX_OVERFLOW	(1U << 31)
 const char *_parse_integer_fixup_radix(const char *s, unsigned int *base);
 unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
 				  size_t max_chars);
-unsigned int _parse_integer(const char *s, unsigned int base, unsigned long long *res);
+
+#define _parse_integer0(s, base, res, ...)						\
+	_parse_integer_limit(s, base, res, INT_MAX);
+
+#define _parse_integer(s, base, res, ...)						\
+	CONCATENATE(_parse_integer, COUNT_ARGS(__VA_ARGS__))(s, base, res, __VA_ARGS__)
 
 #endif
-- 
2.50.1

Re: [PATCH v1 1/2] kstrtox: Make _parse_integer() take variadic arguments

[Andy Shevchenko]

On Tue, Jun 02, 2026 at 10:29:46PM +0200, Andy Shevchenko wrote:
> Instead of having different functions that just use default parameters,
> combine those to use variadic arguments, so the user may call it using
> the same name.

...

Maybe we also need to add a comment here

/* Do NOT call this directly, use _parse_integer() wrapper instead */

>  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
>  				  size_t max_chars);

...

Overall I think independently on the new user (if it comes or not) this change
is good on itself. Petr, what do you think about this?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/2] kstrtox: Make _parse_integer() take variadic arguments

[David Laight]

On Tue,  2 Jun 2026 22:29:46 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> Instead of having different functions that just use default parameters,
> combine those to use variadic arguments, so the user may call it using
> the same name.

Adding a default final parameter can be done generically:

#define one(v) v
#define first(v, ...) v
#define dflt(d, ...) first(__VA_OPT__(one(__VA_ARGS__) ,) d)

int foo(int, int);
#define foo(a, ...) foo(a, dflt(42, ## __VA_ARGS__))

See: https://godbolt.org/z/x5aao7reK

-- David

> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  lib/kstrtox.c | 6 ------
>  lib/kstrtox.h | 9 ++++++++-
>  2 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/kstrtox.c b/lib/kstrtox.c
> index edc4eb7c1bca..adc03e27e4a2 100644
> --- a/lib/kstrtox.c
> +++ b/lib/kstrtox.c
> @@ -94,12 +94,6 @@ unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned lon
>  	return rv | overflow;
>  }
>  
> -noinline
> -unsigned int _parse_integer(const char *s, unsigned int base, unsigned long long *p)
> -{
> -	return _parse_integer_limit(s, base, p, INT_MAX);
> -}
> -
>  static int _kstrtoull(const char *s, unsigned int base, unsigned long long *res)
>  {
>  	unsigned long long _res;
> diff --git a/lib/kstrtox.h b/lib/kstrtox.h
> index 158c400ca865..6c7ca3b67429 100644
> --- a/lib/kstrtox.h
> +++ b/lib/kstrtox.h
> @@ -2,10 +2,17 @@
>  #ifndef _LIB_KSTRTOX_H
>  #define _LIB_KSTRTOX_H
>  
> +#include <linux/args.h>
> +
>  #define KSTRTOX_OVERFLOW	(1U << 31)
>  const char *_parse_integer_fixup_radix(const char *s, unsigned int *base);
>  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
>  				  size_t max_chars);
> -unsigned int _parse_integer(const char *s, unsigned int base, unsigned long long *res);
> +
> +#define _parse_integer0(s, base, res, ...)						\
> +	_parse_integer_limit(s, base, res, INT_MAX);
> +
> +#define _parse_integer(s, base, res, ...)						\
> +	CONCATENATE(_parse_integer, COUNT_ARGS(__VA_ARGS__))(s, base, res, __VA_ARGS__)
>  
>  #endif

Re: [PATCH v1 1/2] kstrtox: Make _parse_integer() take variadic arguments

[Andy Shevchenko]

On Wed, Jun 03, 2026 at 11:37:50AM +0100, David Laight wrote:
> On Tue,  2 Jun 2026 22:29:46 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > Instead of having different functions that just use default parameters,
> > combine those to use variadic arguments, so the user may call it using
> > the same name.
> 
> Adding a default final parameter can be done generically:

Only one?

> #define one(v) v
> #define first(v, ...) v
> #define dflt(d, ...) first(__VA_OPT__(one(__VA_ARGS__) ,) d)
> 
> int foo(int, int);
> #define foo(a, ...) foo(a, dflt(42, ## __VA_ARGS__))
> 
> See: https://godbolt.org/z/x5aao7reK

I know, we support some GCC versions that do not provide it.

551d44200152 ("default_gfp(): avoid using the "newfangled" __VA_OPT__ trick")

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/2] kstrtox: Make _parse_integer() take variadic arguments

[Andy Shevchenko]

On Wed, Jun 03, 2026 at 01:54:43PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 11:37:50AM +0100, David Laight wrote:
> > On Tue,  2 Jun 2026 22:29:46 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> > > Instead of having different functions that just use default parameters,
> > > combine those to use variadic arguments, so the user may call it using
> > > the same name.
> > 
> > Adding a default final parameter can be done generically:
> 
> Only one?
> 
> > #define one(v) v
> > #define first(v, ...) v
> > #define dflt(d, ...) first(__VA_OPT__(one(__VA_ARGS__) ,) d)
> > 
> > int foo(int, int);
> > #define foo(a, ...) foo(a, dflt(42, ## __VA_ARGS__))
> > 
> > See: https://godbolt.org/z/x5aao7reK
> 
> I know, we support some GCC versions that do not provide it.
> 
> 551d44200152 ("default_gfp(): avoid using the "newfangled" __VA_OPT__ trick")

I stand corrected, it's all about sparse. Since this is the generic header,
I would also avoid using VA_OPT even if it allows more than one optional
argument.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/2] kstrtox: Make _parse_integer() take variadic arguments

[David Laight]

On Wed, 3 Jun 2026 13:56:24 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Wed, Jun 03, 2026 at 01:54:43PM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 03, 2026 at 11:37:50AM +0100, David Laight wrote:  
> > > On Tue,  2 Jun 2026 22:29:46 +0200
> > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:  
> 
> > > > Instead of having different functions that just use default parameters,
> > > > combine those to use variadic arguments, so the user may call it using
> > > > the same name.  
> > > 
> > > Adding a default final parameter can be done generically:  
> > 
> > Only one?
> >   
> > > #define one(v) v
> > > #define first(v, ...) v
> > > #define dflt(d, ...) first(__VA_OPT__(one(__VA_ARGS__) ,) d)
> > > 
> > > int foo(int, int);
> > > #define foo(a, ...) foo(a, dflt(42, ## __VA_ARGS__))
> > > 
> > > See: https://godbolt.org/z/x5aao7reK  
> > 
> > I know, we support some GCC versions that do not provide it.
> > 
> > 551d44200152 ("default_gfp(): avoid using the "newfangled" __VA_OPT__ trick")  
> 
> I stand corrected, it's all about sparse. Since this is the generic header,
> I would also avoid using VA_OPT even if it allows more than one optional
> argument.

I'm not sure multiple optional arguments are overly useful.
Starts getting difficult knowing what they are for.

Really the C standard should have added named parameters ages ago.
Perhaps as:
	int f(int a, int b, int c = 0);
then:
	x = f(b:17, a:42);
then you could have default values for any parameters.
Would also be less error prone for functions with lots of flag parameters.

For sparse it only has to expand to valid C.
So how about something like the following for sparse builds?

#define dlft(d, ...) (one(__VA_ARGS__) + 0 ?: (d))

-- David

[PATCH v1 2/2] vsprintf: Convert to use _parse_integer() instead of _parse_integer_limit()

[Andy Shevchenko]

Use _parse_integer() that allows optional arguments to be explicitly
initialised.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 lib/kstrtox.h  | 3 +++
 lib/vsprintf.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/kstrtox.h b/lib/kstrtox.h
index 6c7ca3b67429..4299b1f92133 100644
--- a/lib/kstrtox.h
+++ b/lib/kstrtox.h
@@ -12,6 +12,9 @@ unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned lon
 #define _parse_integer0(s, base, res, ...)						\
 	_parse_integer_limit(s, base, res, INT_MAX);
 
+#define _parse_integer1(s, base, res, max_chars, ...)					\
+	_parse_integer_limit(s, base, res, max_chars);
+
 #define _parse_integer(s, base, res, ...)						\
 	CONCATENATE(_parse_integer, COUNT_ARGS(__VA_ARGS__))(s, base, res, __VA_ARGS__)
 
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index a3017bc58986..1389b50266bf 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -86,7 +86,7 @@ static unsigned long long simple_strntoull(const char *startp, char **endp, unsi
 	cp = _parse_integer_fixup_radix(startp, &base);
 	prefix_chars = cp - startp;
 	if (prefix_chars < max_chars) {
-		rv = _parse_integer_limit(cp, base, &result, max_chars - prefix_chars);
+		rv = _parse_integer(cp, base, &result, max_chars - prefix_chars);
 		/* FIXME */
 		cp += (rv & ~KSTRTOX_OVERFLOW);
 	} else {
-- 
2.50.1

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Petr Mladek]

On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote:
> Currently every new wrapper on _parse_integer_limit() will need a new name
> to share with users while keeping some optional arguments to be initialised
> explicitly. Since there is an attempt to expand this more, I decided to
> suggest this mini series to avoid namespace pollution and unneeded churn in
> the future.
> 
> To expand this API more, the possible future change may be:
> 
>  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
> -                                  size_t max_chars);
> +                                  size_t max_chars, $new_opt_arg);
> 
>  #define _parse_integer0(s, base, res, ...)                                              \
> -        _parse_integer_limit(s, base, res, INT_MAX);
> +        _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default);
> 
>  #define _parse_integer1(s, base, res, max_chars, ...)                                   \
> -        _parse_integer_limit(s, base, res, max_chars);
> +        _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default);
> 
> +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...)                      \
> +        _parse_integer_limit(s, base, res, max_chars, new_opt_arg);

I guess that this is about _parse_integer_limit_init() from
https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com/

I personally find

    _parse_integer(*s, base. *res)
    _parse_integer_limit(*s, base, *res, max_chars)
    _parse_integer_limit_init(*s, base, init, *res, max_chars)

a bit more self-explanatory than

    _parse_integer(*s, base. *res)
    _parse_integer(*s, base, *res, max_chars)
    _parse_integer(*s, base, *res, max_chars, init)

especially when the meaning of the arguments need not be obvious
when the function is used in the code.

Also the macro magic increases the complexity of the code.

On the other hand, I do not have strong opinion. It is not a big deal.
I am not going to block it.

> So you got the idea. (It is roughly overloaded function in OOP.)

Best Regards,
Petr

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Rodrigo Alencar]

On 26/06/03 01:23PM, Petr Mladek wrote:
> On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote:
> > Currently every new wrapper on _parse_integer_limit() will need a new name
> > to share with users while keeping some optional arguments to be initialised
> > explicitly. Since there is an attempt to expand this more, I decided to
> > suggest this mini series to avoid namespace pollution and unneeded churn in
> > the future.
> > 
> > To expand this API more, the possible future change may be:
> > 
> >  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
> > -                                  size_t max_chars);
> > +                                  size_t max_chars, $new_opt_arg);
> > 
> >  #define _parse_integer0(s, base, res, ...)                                              \
> > -        _parse_integer_limit(s, base, res, INT_MAX);
> > +        _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default);
> > 
> >  #define _parse_integer1(s, base, res, max_chars, ...)                                   \
> > -        _parse_integer_limit(s, base, res, max_chars);
> > +        _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default);
> > 
> > +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...)                      \
> > +        _parse_integer_limit(s, base, res, max_chars, new_opt_arg);
> 
> I guess that this is about _parse_integer_limit_init() from
> https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com/
> 
> I personally find
> 
>     _parse_integer(*s, base. *res)
>     _parse_integer_limit(*s, base, *res, max_chars)
>     _parse_integer_limit_init(*s, base, init, *res, max_chars)
>

What could also be done is having a _parse_integer_ext() that would
contain all the necessary arguments (one that should be indicated
not to be used) and define all the other variations as static inline
functions. I suppose that combines both ideas, being a pattern that
is also used elsewhere:

	devm_regulator_get()
	devm_regulator_get_enable()
	devm_regulator_get_enable_optional() 
 
> a bit more self-explanatory than
> 
>     _parse_integer(*s, base. *res)
>     _parse_integer(*s, base, *res, max_chars)
>     _parse_integer(*s, base, *res, max_chars, init)
> 
> especially when the meaning of the arguments need not be obvious
> when the function is used in the code.
> 
> Also the macro magic increases the complexity of the code.
> 
> On the other hand, I do not have strong opinion. It is not a big deal.
> I am not going to block it.
> 
> > So you got the idea. (It is roughly overloaded function in OOP.)
> 
> Best Regards,
> Petr

-- 
Kind regards,

Rodrigo Alencar

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Rodrigo Alencar]

On 26/06/03 12:51PM, Rodrigo Alencar wrote:
> On 26/06/03 01:23PM, Petr Mladek wrote:
> > On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote:
> > > Currently every new wrapper on _parse_integer_limit() will need a new name
> > > to share with users while keeping some optional arguments to be initialised
> > > explicitly. Since there is an attempt to expand this more, I decided to
> > > suggest this mini series to avoid namespace pollution and unneeded churn in
> > > the future.
> > > 
> > > To expand this API more, the possible future change may be:
> > > 
> > >  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
> > > -                                  size_t max_chars);
> > > +                                  size_t max_chars, $new_opt_arg);
> > > 
> > >  #define _parse_integer0(s, base, res, ...)                                              \
> > > -        _parse_integer_limit(s, base, res, INT_MAX);
> > > +        _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default);
> > > 
> > >  #define _parse_integer1(s, base, res, max_chars, ...)                                   \
> > > -        _parse_integer_limit(s, base, res, max_chars);
> > > +        _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default);
> > > 
> > > +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...)                      \
> > > +        _parse_integer_limit(s, base, res, max_chars, new_opt_arg);
> > 
> > I guess that this is about _parse_integer_limit_init() from
> > https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com/
> > 
> > I personally find
> > 
> >     _parse_integer(*s, base. *res)
> >     _parse_integer_limit(*s, base, *res, max_chars)
> >     _parse_integer_limit_init(*s, base, init, *res, max_chars)
> >
> 
> What could also be done is having a _parse_integer_ext() that would
> contain all the necessary arguments (one that should be indicated
> not to be used) and define all the other variations as static inline
> functions. I suppose that combines both ideas, being a pattern that
> is also used elsewhere:
> 
> 	devm_regulator_get()
> 	devm_regulator_get_enable()
> 	devm_regulator_get_enable_optional() 

Actually the example pattern with static inline is not this one, it is
under linux/reset.h with __devm_reset_control_get().

If every one agrees I can add that to the v16 of the patch series
of the PLL driver.
  
-- 
Kind regards,

Rodrigo Alencar

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Andy Shevchenko]

On Wed, Jun 03, 2026 at 01:10:11PM +0100, Rodrigo Alencar wrote:
> On 26/06/03 12:51PM, Rodrigo Alencar wrote:
> > On 26/06/03 01:23PM, Petr Mladek wrote:

...

> Actually the example pattern with static inline is not this one, it is
> under linux/reset.h with __devm_reset_control_get().
> 
> If every one agrees I can add that to the v16 of the patch series
> of the PLL driver.

...which shows disadvantage of the naming (it grows quite rapidly towards the nonsense,
like devm_reset_control_array_get_exclusive_released().

Again, that's public API and I see at least some value in that. In more closed
one as we discuss in this thread that adds no value.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Andy Shevchenko]

On Wed, Jun 03, 2026 at 12:51:09PM +0100, Rodrigo Alencar wrote:
> On 26/06/03 01:23PM, Petr Mladek wrote:
> > On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote:
> > > Currently every new wrapper on _parse_integer_limit() will need a new name
> > > to share with users while keeping some optional arguments to be initialised
> > > explicitly. Since there is an attempt to expand this more, I decided to
> > > suggest this mini series to avoid namespace pollution and unneeded churn in
> > > the future.
> > > 
> > > To expand this API more, the possible future change may be:
> > > 
> > >  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
> > > -                                  size_t max_chars);
> > > +                                  size_t max_chars, $new_opt_arg);
> > > 
> > >  #define _parse_integer0(s, base, res, ...)                                              \
> > > -        _parse_integer_limit(s, base, res, INT_MAX);
> > > +        _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default);
> > > 
> > >  #define _parse_integer1(s, base, res, max_chars, ...)                                   \
> > > -        _parse_integer_limit(s, base, res, max_chars);
> > > +        _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default);
> > > 
> > > +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...)                      \
> > > +        _parse_integer_limit(s, base, res, max_chars, new_opt_arg);
> > 
> > I guess that this is about _parse_integer_limit_init() from
> > https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com/
> > 
> > I personally find
> > 
> >     _parse_integer(*s, base. *res)
> >     _parse_integer_limit(*s, base, *res, max_chars)
> >     _parse_integer_limit_init(*s, base, init, *res, max_chars)
> 
> What could also be done is having a _parse_integer_ext() that would
> contain all the necessary arguments (one that should be indicated
> not to be used) and define all the other variations as static inline
> functions. I suppose that combines both ideas, being a pattern that
> is also used elsewhere:
> 
> 	devm_regulator_get()
> 	devm_regulator_get_enable()
> 	devm_regulator_get_enable_optional() 

devm_regulator_get*() are public APIs and that split might make sense. The
_parse_integer() is internal to printf() implementation and wrappers around it,
so I don't think we should really be so picky. TL;DR: I think my approach is
good enough and makes not much of turbulence here, perhaps a comment would be
nice to have to explain the list of optional arguments.

> > a bit more self-explanatory than
> > 
> >     _parse_integer(*s, base. *res)
> >     _parse_integer(*s, base, *res, max_chars)
> >     _parse_integer(*s, base, *res, max_chars, init)
> > 
> > especially when the meaning of the arguments need not be obvious
> > when the function is used in the code.
> > 
> > Also the macro magic increases the complexity of the code.
> > 
> > On the other hand, I do not have strong opinion. It is not a big deal.
> > I am not going to block it.

Would you give your tag in case Rodrigo wants to incorporate these into his
series and go via IIO tree? (I think that these two makes sense to put into
immutable branch/tag and share with the users).

> > > So you got the idea. (It is roughly overloaded function in OOP.)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Petr Mladek]

On Wed 2026-06-03 16:53:49, Andy Shevchenko wrote:
> On Wed, Jun 03, 2026 at 12:51:09PM +0100, Rodrigo Alencar wrote:
> > On 26/06/03 01:23PM, Petr Mladek wrote:
> > > On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote:
> > > > Currently every new wrapper on _parse_integer_limit() will need a new name
> > > > to share with users while keeping some optional arguments to be initialised
> > > > explicitly. Since there is an attempt to expand this more, I decided to
> > > > suggest this mini series to avoid namespace pollution and unneeded churn in
> > > > the future.
> > > > 
> > > > To expand this API more, the possible future change may be:
> > > > 
> > > >  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
> > > > -                                  size_t max_chars);
> > > > +                                  size_t max_chars, $new_opt_arg);
> > > > 
> > > >  #define _parse_integer0(s, base, res, ...)                                              \
> > > > -        _parse_integer_limit(s, base, res, INT_MAX);
> > > > +        _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default);
> > > > 
> > > >  #define _parse_integer1(s, base, res, max_chars, ...)                                   \
> > > > -        _parse_integer_limit(s, base, res, max_chars);
> > > > +        _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default);
> > > > 
> > > > +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...)                      \
> > > > +        _parse_integer_limit(s, base, res, max_chars, new_opt_arg);
> > > 
> > > I guess that this is about _parse_integer_limit_init() from
> > > https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com/
> > > 
> > > I personally find
> > > 
> > >     _parse_integer(*s, base. *res)
> > >     _parse_integer_limit(*s, base, *res, max_chars)
> > >     _parse_integer_limit_init(*s, base, init, *res, max_chars)
> > 
> > What could also be done is having a _parse_integer_ext() that would
> > contain all the necessary arguments (one that should be indicated
> > not to be used) and define all the other variations as static inline
> > functions. I suppose that combines both ideas, being a pattern that
> > is also used elsewhere:
> > 
> > 	devm_regulator_get()
> > 	devm_regulator_get_enable()
> > 	devm_regulator_get_enable_optional() 
> 
> devm_regulator_get*() are public APIs and that split might make sense. The
> _parse_integer() is internal to printf() implementation and wrappers around it,
> so I don't think we should really be so picky. TL;DR: I think my approach is
> good enough and makes not much of turbulence here, perhaps a comment would be
> nice to have to explain the list of optional arguments.
> 
> > > a bit more self-explanatory than
> > > 
> > >     _parse_integer(*s, base. *res)
> > >     _parse_integer(*s, base, *res, max_chars)
> > >     _parse_integer(*s, base, *res, max_chars, init)
> > > 
> > > especially when the meaning of the arguments need not be obvious
> > > when the function is used in the code.
> > > 
> > > Also the macro magic increases the complexity of the code.
> > > 
> > > On the other hand, I do not have strong opinion. It is not a big deal.
> > > I am not going to block it.
> 
> Would you give your tag in case Rodrigo wants to incorporate these into his
> series and go via IIO tree? (I think that these two makes sense to put into
> immutable branch/tag and share with the users).

Feel free to use for both patches:

Acked-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Andy Shevchenko]

On Thu, Jun 04, 2026 at 08:59:07AM +0200, Petr Mladek wrote:
> On Wed 2026-06-03 16:53:49, Andy Shevchenko wrote:

...

> Feel free to use for both patches:
> 
> Acked-by: Petr Mladek <pmladek@suse.com>

Thank you, Petr!

Rodrigo, can you incorporate this into your series, please?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Rodrigo Alencar]

On 26/06/04 10:19AM, Andy Shevchenko wrote:
> On Thu, Jun 04, 2026 at 08:59:07AM +0200, Petr Mladek wrote:
> > On Wed 2026-06-03 16:53:49, Andy Shevchenko wrote:
> 
> ...
> 
> > Feel free to use for both patches:
> > 
> > Acked-by: Petr Mladek <pmladek@suse.com>
> 
> Thank you, Petr!
> 
> Rodrigo, can you incorporate this into your series, please?

Will do, thank you!
 
-- 
Kind regards,

Rodrigo Alencar