On 10/20/2026 12:19 AM, Stephen Hemminger wrote:
> On Mon, 19 Oct 2026 16:36:12 +0800
> fengchengwen <[email protected]> wrote:
>
>>> When `step` is large and `min + step` exceeds `INT32_MAX`, the loop counter
>>> wraps around to a negative value, creating an infinite loop. The variables
>>> `min` and `max` are `int` (32-bit signed), and `step` is `int32_t`. If a
>>> malicious or mistaken user provides input like `"0-100:2147483647"`, the
>>> addition `min += step` will overflow after the first iteration.
>>
>> False positive, the:
>> errno = 0;
>> idx = strtol(value, &end, 10);
>> last = end;
>> if (errno || idx > UINT16_MAX) {
>> ARGPARSE_LOG(ERR, "argument %s contains a numerical
>> value out of range!",
>> arg->name_long);
>> return -EINVAL;
>> }
>> already treat such input as an error.
>
> Since non-negative steps don't make sense, I would use strtoul() instead
> and bound it by MAX_LCORE
Hi Stephen,
Thanks for your suggestion.
While using strtoul() and bounding by MAX_LCORE sounds logical, I prefer to keep
the current implementation for the following reasons:
1. Current validation is already safe: if using strtoul() we should also keep
"
if (!isdigit(*value)) {
ARGPARSE_LOG(ERR, "argument %s has an unexpected non
digit character!",
arg->name_long);
return -EINVAL;
}
"
because we don't want "+1" as a valid input.
If there has no error, then idx is valid in [0, LONG_MAX], it will never be
negative in
the following execute flow.
2. MAX_LCORE varies across platforms: MAX_LCORE is a build-time configuration
that heavily
depends on the target SoC. On some resource-constrained or specific SoCs,
MAX_LCORE might
be configured to a very small number (e.g., 4). If we enforce MAX_LCORE as a
hard limit for
the step value, it will cause certain valid test cases or generalized step
ranges to fail
prematurely on those platforms, reducing the robustness of the argparse
library.
Best regards,
Chengwen
>
