|WARNING| mempool/cnxk: fix halo enable devarg parsing

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/172257

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-10-30

# DPDK Patch Review

## Correctness Issues

### Error: Integer overflow in range check

**File:** `drivers/mempool/cnxk/cnxk_mempool.c`
**Line:** `val = atoi(value);`

The `atoi()` function returns `int`, which can represent values outside the 0-1 range this function intends to enforce. When `val` is assigned from `atoi()`, values like 256 will be stored correctly in the `uint32_t`. However, the current implementation has a subtle bug: the range check `if (val != 0 && val != 1)` will correctly reject 256 after this patch, but the use of `atoi()` itself is problematic because:

1. `atoi()` has no error reporting - invalid input returns 0
2. `atoi()` can overflow on very large inputs with undefined behavior
3. Negative inputs like "-1" will pass `atoi()` but be stored as a large unsigned value due to implicit conversion

**Suggested fix:**
Use `strtoul()` with proper error checking:

```c
parse_halo_ena_handler(const char *key, const char *value, void *extra_args)
{
	RTE_SET_USED(key);
	char *end;
	unsigned long val;

	errno = 0;
	val = strtoul(value, &end, 10);
	if (errno != 0 || *end != '\0' || val > 1)
		return -EINVAL;

	*(uint32_t *)extra_args = val;
	return 0;
}
```

## Style Issues

### Warning: Missing error handling

The use of `atoi()` without checking for parse errors means invalid input like "abc" or "" will silently return 0, which then passes validation. While `strtoul()` is recommended above for correctness, at minimum the current code should validate that the string is numeric.

### Info: Function can be simplified

The check `if (val != 0 && val != 1)` could be written more clearly as `if (val > 1)` given that `val` is unsigned after this patch. However, this is a minor style preference.

## Documentation

No documentation updates are required for this internal fix.

## Summary

The patch correctly identifies and fixes the type mismatch issue where a `uint32_t` was being written through a `uint8_t` pointer. However, the continued use of `atoi()` leaves error handling gaps that should be addressed. The range validation will work correctly with the type fix, but input parsing remains fragile.

**Final assessment:** The patch improves the code but the use of `atoi()` without error checking is a correctness issue that should be fixed.

Review-Result: ERROR