一场横跨六年的代码清理
2026 年 6 月 20 日，Linux 7.2 合并窗口接受了一组 hardening 子系统更新，将 strncpy API 从内核中正式消除。这次合并移除了 strncpy 的全部内核内调用者，同时清理了各 CPU 架构剩余的 strncpy 汇编实现。Phoronix 率先报道了这一里程碑事件，HN 讨论在数小时内积累了超过 200 条评论。
这项工作的推进者是内核安全子系统维护者 Kees Cook。根据其在 Mastodon 发布的总结数据，整个清理过程持续六年，累计提交 362 个补丁，来自 70 位贡献者。贡献最密集的开发者包括 Justin Stitt（211 个提交）、Xu Panda（22 个）、Kees Cook 本人（21 个）、Thorsten Blum（17 个）和 Arnd Bergmann（12 个）。Justin Stitt 承担了清理任务的主体工作量。
strncpy 为何成为"持续性错误来源"
内核文档将 strncpy 定性为"持久性错误来源"（persistent source of bugs），根源在于其反直觉的语义设计。strncpy 的核心问题有两条：第一，当源字符串长度大于或等于目标缓冲区大小时，strncpy 不会在目标末尾写入 NUL 终止符——这意味着下游代码如果假定结果为合法 C 字符串，将触发线性读取溢出。第二，当源字符串短于目标缓冲区时，strncpy 会用 NUL 字节填充目标剩余空间，这在仅需 NUL 终止字符串的场景下构成不必要的性能开销。
更隐蔽的是，strncpy 的名称暗示其行为类似 strcpy 的"安全"版本，但实际上 strncpy 最初被设计用于将字符串写入固定宽度的填充字段——这是 Unix 文件系统目录项等早期数据结构的遗留需求。在绝大多数以 NUL 终止字符串为目标的场景中，调用 strncpy 几乎总是错误的选择。HN 上有评论精确概括了这一状况："strncpy 在 99.999% 的情况下不是正确的调用函数。"
而 strncpy 被"推荐使用"的情况——即复制到非 NUL 终止的固定宽度字段——在实际内核代码中占比极低。绝大多数调用者真正需要的只是一个能保证 NUL 终止的字符串复制函数。
替代方案的五层矩阵
内核社区提供了一组按使用场景分层的替代 API，将原本 strncpy 承担的模糊职责拆解为多个语义明确的函数。对于以 NUL 终止为目标的字符串复制，标准替代是 strscpy()。该函数由 Chris Metcalf 于 2015 年引入内核，保证目标缓冲区始终以 NUL 终止，并返回实际复制的非 NUL 字节数（截断时返回负值 errno）。如果需要 NUL 终止同时保留零填充行为（例如将缓冲区拷贝到用户空间前确保不泄露内核数据），则应使用 strscpy_pad()。
对于不以 NUL 终止为目标的固定宽度字段，strtomem() 系列替代了 strncpy 的原始用途，配套使用 GCC 的 __nonstring 属性标记目标缓冲区以避免编译器误报。需要零填充时使用 strtomem_pad()。对于长度已知的纯粹内存复制，直接使用 memcpy()；需要显式填充的边界复制则使用 memcpy_and_pad()。这种按意图显式分层的 API 设计，将原本隐藏在 strncpy 单一接口中的多种语义决策暴露为编译期可见的选择，从根本上消除了"用错了但编译器不知道"的隐患。
Linus Torvalds 的审慎节奏
尽管 strscpy 在 2015 年已合并至内核，但当时 Linus Torvalds 明确划定了迁移的边界。他在 LKML 邮件中写道："鼓励在新代码中审慎使用 strscpy()，或在因修复 bug、其他更新原因而修改的代码中使用……但我不会接受对 strlcpy 或 strncpy 进行大规模转换的补丁。"
这一立场决定了后续六年的工作节奏：放弃一次性批量替换，改为在子系统正常演进的过程中逐文件、逐调用点地完成迁移。每次代码因其他原因被触及，就顺带替换一个 strncpy 调用。这种方式避免了因大规模机械性改动引入回归，同时迁移速度受限于各子系统的自然开发频率。
从结果看，362 个补丁的平均粒度约为每次提交处理不到 10 个调用点。这些改动散布在驱动、文件系统、网络、架构代码等几乎所有内核子系统中，体现了真正的全树级别清理。
基础设施工程的尺度
HN 讨论中，多位评论者将这一事件置于更宏观的语境下审视。有人指出，这种"枯燥的打磨工作"恰恰是系统工程真正发生的地方——提升内核可靠性的大型基础设施项目以十年为尺度推进。
另一条线索则指向 C 语言本身的局限。多位评论者追溯到 Dennis Ritchie 在 1990 年提出的"胖指针"（fat pointer）提案——一个同时包含起始地址和长度的指针类型，本可以成为 C99 的原生字符串抽象。Walter Bright 在 2007 年的《C 语言的最大错误》一文中以更清晰的语言重申了同一主张。然而直至 C23，C 标准委员会仍未采纳这类切片/字符串视图类型。
内核选择在语言的现状约束下完成工程改进，而非等待语言标准的演进。strscpy 和配套 API 本质上是在 C 的类型系统之外建立了一套按意图分层的命名约定和语义契约。六个替代函数的区分依赖的是开发者的人工判断和代码审查，而非编译器强制。
最后六个调用点
Kees Cook 在 Mastodon 中提到："我处理了最后 6 个实例，并移除了所有实现。"这意味着在六年清理的尾声，内核树中仅存个位数的 strncpy 调用。这些最后残留的调用点很可能位于冷路径或历史代码中，最终由维护者亲手完成收官。
合并后，strncpy 的函数定义从内核源码树中消失。任何未来试图向内核提交包含 strncpy 调用的补丁，将在编译阶段失败。内核的 deprecated.rst 文档中关于 strncpy 的条目，从"不应在新代码中使用"升级为"已从内核中移除"。
Linux 内核以数百万行 C 代码的体量完成了一次底层字符串 API 的彻底换代。整个过程未引入重大的回归事故，未打断任何子系统的正常开发节奏。作为内核安全加固中的一条工作线，strncpy 的消除与同期推进的 Rust 语言引入、VLA 清理、format 字符串加固等项目共同构成了内核安全架构演进的拼图。
