|WARNING| [v3] net/ark: use standard IPv4 address parser

[dpdklab at iol.unh.edu]

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

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-06-08

# DPDK Patch Review: net/ark: use standard IPv4 address parser

## Summary

This patch replaces hand-rolled IPv4 address parsing in the ARK driver with the standard `inet_pton()` function. The change fixes a correctness bug where invalid octets (>255) were accepted and incorrectly encoded into device registers.

---

## Errors

None found.

---

## Warnings

None found.

---

## Info

### Correctness and Security

**Positive findings:**

1. **Fixes a real bug**: The original `sscanf()` with `%u` accepts values >255, which would be truncated when stored in registers. The patch correctly addresses this.

2. **inet_pton() is the right choice**: It validates both format and octet ranges, matching what other DPDK drivers use.

3. **Byte order handling is correct**: The patch uses `rte_be_to_cpu_32(addr.s_addr)` which produces the same result as the old code for valid input (both assemble octets in network byte order then convert to host).

4. **Error handling preserved**: Both functions return 0 on parse failure, maintaining the existing error handling contract.

5. **No resource leaks**: `inet_pton()` takes a user-provided buffer (`struct in_addr`), so there's no allocation to leak.

### Code Style

The patch is well-formatted and follows DPDK conventions:

- Includes are properly ordered (system headers, then DPDK headers)
- The new `#include <sys/socket.h>` for `AF_INET` is correctly placed
- Function signature unchanged (static, return type on own line)
- Uses DPDK byte-order API (`rte_be_to_cpu_32`) rather than POSIX `ntohl()`

### Documentation

The commit message clearly explains:
- What the bug was (accepts >255 octets)
- Why `inet_pton()` is the fix (validates format and range)
- That output is unchanged for valid input

The `Fixes:` tag and `Cc: stable at dpdk.org` are appropriate for a correctness fix.

### Testing Note

While not required by this review, the patch would benefit from a test case in `app/test` that verifies rejection of invalid octets like "256.1.1.1" or "1.2.3.999". The existing code would have silently accepted these and produced wrong register values.

---

## Conclusion

**The patch is correct and ready for merge.** It fixes a real input validation bug, uses the standard library function that other DPDK code already relies on, and maintains compatibility for valid inputs.