|WARNING| argparse: support range step for corelist parsing

[fengchengwen]

On 10/20/2026 12:19 AM, Stephen Hemminger wrote:
> On Mon, 19 Oct 2026 16:36:12 +0800
> fengchengwen <fengchengwen at huawei.com> 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

>