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@xxxxxxxxxx/
> 
> 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