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

[Petr Mladek <pmladek@suse.com>]

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