经过六年努力和超过360个补丁，Linux内核终于移除了存在安全风险的strncpy API，改用更安全的函数替代。

经过六年努力和超过360个补丁，Linux 7.2内核终于彻底移除了strncpy API。strncpy()函数因语义反直觉、NUL终止行为易引发bug以及冗余零填充导致的性能问题，长期被视为“持续性的bug来源”。此次移除涉及约362次提交，并删除了各CPU架构的最后实现。替代方案包括：针对NUL终止字符串使用strscpy()，需零填充时用strscpypad()，处理非NUL终止固定宽度字段用strtomempad()，显式填充的边界拷贝用memcpyandpad()，已知长度内存拷贝则用memcpy()。

根据评论内容，总结如下：

主要观点与论据：

1. strncpy 是长期存在的缺陷（评分：无，但多位作者强烈批评）

   • 多位评论者指出 strncpy 语义反直觉、易引发 bug，且性能低下（如冗余零填充）。
   • 关键引用：mrlonglong "the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer."；WalterBright "I always looked for strncpy and always found a bug with it."

2. 替代方案与历史争议（评分：无，观点对立）

   • 部分评论者认为应使用更安全的字符串处理方式（如结构体+长度），或提及 strlcpy 未被 Linux 内核接受是“开源内耗”。
   • 关键引用：naturalmovement "strlcpy... was never accepted into the Linux world because of typical petty open source bullshit."；senfiaj "why not use a string buffer paired with its length?"

3. 工程价值与实现方式（评分：无，正面评价）

   • 多数评论者认可移除 strncpy 是重要的系统工程，需要长期耐心，并赞扬贡献者。
   • 关键引用：lambdaone "This sort of boring grind is where the real work of systems engineering is done."；twothreeone "removing bad features is even more important for something as fundamental as the kernel."

4. 对 AI 辅助的讨论（评分：无，观点分歧）

   • 有评论者质疑是否可用 LLM 自动完成此类工作，但未获明确支持或反对。
   • 关键引用：qarl "Wouldn't this work be extremely easy to implement with an LLM coder?"；Animats "This is a job for Claude!"

平衡性说明： 评论整体对 strncpy 移除持积极态度，但对其历史原因（如未采用 strlcpy）存在争议；AI 辅助的讨论仅作为补充观点，未形成主流。