|WARNING| build: use native Linux strlcpy when available

dpdklab at iol.unh.edu dpdklab at iol.unh.edu
Wed Jun 24 18:30:32 CEST 2026


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

_AI Code Review_

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

# DPDK Patch Review

## Patch: "build: use native Linux strlcpy when available"

---

## ERRORS

None found.

---

## WARNINGS

### 1. Missing release notes update

**Issue:** This patch changes the build system's behavior regarding `strlcpy`/`strlcat` function detection and affects how DPDK links against libbsd. This is a user-visible change that should be documented in the release notes.

**Why it matters:** Users building DPDK on newer glibc (2.38+) systems will no longer link against libbsd for `strlcpy`/`strlcat`, which may affect their build environment requirements and dependency management.

**Suggested fix:** Add an entry to `doc/guides/rel_notes/release_26_03.rst` (or the appropriate current release notes file) in a "Removed Items" or "Build System" section:

```rst
* **Updated strlcpy/strlcat detection.**

  DPDK now detects and uses native ``strlcpy`` and ``strlcat`` functions
  from glibc 2.38+ when available, falling back to libbsd only if needed.
  This reduces dependencies on systems with modern glibc.
```

---

## INFO

### 1. Consider documenting the detection order in code comments

The new detection logic in `config/meson.build` is clear but a brief comment explaining the detection order would help future maintainers:

```python
# check for strlcpy: first in native libc, then via libbsd as fallback
# glibc 2.38+ provides native strlcpy/strlcat, older systems may need libbsd
if cc.has_function('strlcpy', prefix: '#include <string.h>')
```

This is a nice-to-have, not required.

### 2. The empty dependency pattern is correct

The line `libbsd = dependency('', required: false)` creates an empty not-found dependency object. This is the correct meson pattern for representing "no dependency needed" and allows the variable to be referenced later without conditionals. No issue here.

---

## SUMMARY

**Overall assessment:** The patch is correct and follows DPDK coding standards. The logic is sound:

1. First checks for native `strlcpy` in libc (glibc 2.38+)
2. Falls back to libbsd if not found
3. Updates `rte_string_fns.h` to use the appropriate source based on detection results

The only actionable item is adding a release notes entry documenting this build system change for users.


More information about the test-report mailing list