Claude review: Use safer strscpy() instead of strcpy()

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: Use safer strscpy() instead of strcpy()
Author: Ai Chao <aichao@kylinos.cn>
Patches: 22
Reviewed: 2026-04-28T15:38:38.793275

---

This is a 35-patch mechanical series (19 patches CC'd to dri-devel) replacing `strcpy()` with `strscpy()` across fbdev drivers. The stated goal is correct — `strscpy()` is the preferred API for copying strings into fixed-size arrays in the modern kernel, and the kernel community has been systematically driving this conversion.

**All replacements are safe**: in every case, the source string literals fit comfortably within their destination buffers (`fb_fix_screeninfo.id` is `char[16]`, `i2c_adapter.name` is `char[48]`, SiS `myid` is `char[40]`, etc.). The `strscpy()` 2-argument form (destination size inferred via `sizeof`) works correctly here because the destinations are all arrays, not pointers.

**Issues found:**
1. **Patch 02 (i810)** silently changes indentation from spaces to tabs on the modified lines, which contradicts the commit message claim of "only idiomatic code replacement."
2. **Patch 05 (atafb)** modifies a commented-out line, which is pointless.
3. **Patch 03 (sisfb)** — the `strbuf1` conversion is safe but subtly different from the rest of the series: it copies from a variable `name` (not a string literal) into `char strbuf1[20]`, guarded by `strlen(name) <= 19`. This is safe but is a genuine behavioral change — `strscpy()` will NUL-terminate and silently truncate, where `strcpy()` would overflow. Worth noting in the commit message.
4. The patches did not apply cleanly, suggesting some of these conversions may already exist upstream.
5. A 35-patch series for trivial s/strcpy/strscpy/ is arguably excessive; a Coccinelle spatch would be more appropriate and reviewable.

**Verdict**: Low-risk mechanical cleanup. Correct in substance, with minor nits on patches 02, 03, and 05.

---

---
Generated by Claude Code Patch Reviewer