lib/kstrtox.c | 6 ------ lib/kstrtox.h | 12 +++++++++++- lib/vsprintf.c | 2 +- 3 files changed, 12 insertions(+), 8 deletions(-)
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
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
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.