# 

上游传一个文件名过来，服务把它拼在固定长度的目录后面，再打开。短名字一直没出过事，某天来了一个八十多字符的名字，进程直接崩了，core 里显示堆上的数据被写坏。

问题不在名字太长，而在拼接时对第三个参数的理解错了整整一格。

## 那个参数到底限制谁？

拼接函数有三个参数：目标、源、以及一个长度。绝大多数人把它当成「目标缓冲区还能装多少」，实际含义是「最多从源里取多少字节」。

> appends at most ssize non-null bytes from the string pointed to by src to the end of the string pointed to by dest, and then adds a terminating null byte.

翻译：最多把源字符串里的 ssize 个非空字节追加到目标字符串的末尾，然后补一个终止空字符。

关键点有两个：限制作用在「源」上，追加位置在「目标的末尾」，而且无论取了多少，末尾那个空字符都要写。

## 需要多大的目标缓冲区？

按上一句推，需要的空间是目标原有长度、实际取用的源长度、加上末尾空字符三者之和。

> the size of dest must be at least strlen(dest) + strnlen(src, ssize) + 1

也就是：已有长度加上源里最多取 ssize 字节后的实际长度，再加一。注意中间那项是取小值之后的长度，不是 ssize 本身——如果源比 ssize 短，只算实际长度。

这条式子暴露了最常见的错误：把目标总大小当作第三个参数传进去。目标里已经有内容时，这样写需要的空间是「已有长度加目标总大小再加一」，必然超出。

## 为什么这种写法一直没炸？

因为它只在目标已有内容、且源足够长时才越界。短名字、空目标的情况下，结果刚好落在界内。

| 写法 | 传的参数 | 目标已有内容时的结果 |
| --- | --- | --- |
| 传目标总大小 | 数组总长 | 越界写，破坏相邻内存 |
| 传剩余空间 | 总长减已有长度 | 正确，但每次都要算 |
| 传剩余空间减一 | 上式再减一 | 保守，安全但会少一个字符 |
| 传源的长度上限 | 业务上限 | 与目标无关，仍需自行校验 |

第一行就是这次的事故写法。它在压测里也很难复现，因为压测路径通常短，边界值只有真实数据才会撞上。

我们复盘时发现了一个规律：这类越界几乎都由「第二次拼接」触发。第一次拼接时目标还是空的，怎么传都不会越界；第二次之后目标里有了内容，同样的参数就开始生效。

第三行的「少一个字符」不是缺陷，是给末尾空字符让位。少这一个字符，换来的是确定性。

## 目标没初始化会怎样？

手册在注意事项里写得很清楚：目标必须是已经以空字符结尾的字符串，且空间足够；否则行为未定义。

「未定义」在这里不是「可能少拼几个字符」，而是「可能写到任何地方」。常见的表现是相邻变量被改、结构体里的指针被覆盖、释放时直接崩溃。这类崩溃的位置往往离真正的错误很远，排查成本很高。

还有两点常被误解。一是这个函数与另一个名字相近的拷贝函数没有关系，两者的参数含义不同，不能互相套用。二是它不会截断输入——它只限制取用多少，不会因为目标放不下就提前收手。

换句话说，它做的事情是「有节制地取用」，而不是「有节制地写入」。这个措辞差别，就是事故的样子。

## 长度参数的信任边界

带长度参数的函数本来是为了防溢出，但它只防住了一半：源的长度被限制了，目标的空间仍然要调用方自己保证。

这个不对称很容易让人放松警惕，因为签名里出现了「长度」两个字，读代码的人下意识以为风险已经兜住了。

真正的边界是：目标有多大，只有调用方知道；源有多少，函数自己会判断。所以第三个参数该给的，是「目标还能腾出多少」，而不是「源最多能有多长」。前者是空间问题，后者是数据问题，混用就会出事。

## 正确的写法有几种？

按场景选。目标确定足够大、且知道剩余空间时，先算再拼：

```c
/* 先算剩余空间，第三个参数是「还能追加多少」 */
size_t used = strlen(dst);
size_t room = sizeof(dst) - used;          /* 含末尾空字符 */
if (room > 1) {
    strncat(dst, src, room - 1);           /* 最多填满再留一位 */
}
```

这段的关键是第三个参数取「剩余空间减一」，因为函数最后还要写一个空字符。

更稳的做法是根本不用拼接，直接按格式一次成型：

```c
/* 一次性格式化，返回实际需要的长度，可判断是否被截断 */
int n = snprintf(dst, sizeof(dst), "%s/%s", prefix, name);
if (n < 0 || (size_t)n >= sizeof(dst)) {
    /* 截断或出错，按业务决定拒绝还是继续 */
}
```

第二种写法把「需要多少」和「能装多少」放在同一行，截断可以被检测到，而不是悄悄发生。

## 三种做法怎么选？

| 做法 | 截断能否察觉 | 风险 |
| --- | --- | --- |
| 先算剩余再拼 | 能，靠人工保证 | 算错就退化成越界 |
| 一次格式化 | 能，返回值即依据 | 需要检查返回值 |
| 先量长度再分配 | 不需要截断 | 多一次分配，要记得释放 |

第一行的问题在于正确性依赖人的计算，第二行的正确性依赖返回值检查，第三行最彻底但引入了内存管理。

对拼接固定两段的场景，第二行足够；如果是拼接不定长的多段，第三行更省心。选错的代价不对称：第一行出错是崩溃，第二行出错只是拿不到完整字符串。

## 编译期能不能拦住？

部分能。开启源码加固后，编译器能在已知目标大小时插入检查，越界会直接终止进程，而不是静默写坏内存。

```bash
# 开启加固与常见告警，越界写会尽早暴露
gcc -O2 -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wstringop-overflow -c concat.c
```

| 检查手段 | 能发现 | 看不到 |
| --- | --- | --- |
| 源码加固 | 编译期已知大小的越界 | 动态分配的目标 |
| 编译告警 | 常量越界、明显溢出 | 运行期算出的偏移 |
| 运行时检测 | 实际发生的越界写 | 没被触发的路径 |
| 代码评审 | 参数含义用错 | 依赖人工细心 |

这四种手段是叠加使用的关系，不是替代关系。只开加固不开告警，只能抓住一部分；只靠评审不看工具，等于把结果交给运气。

还有一条成本更低的检查：把目标声明为定长数组，不要用指针。定长数组能让编译器知道大小，几乎所有静态检查都依赖这个信息；一旦退化成指针，检查基本失效。

## 怎么在整仓范围排查？

按参数形态粗筛：第三个参数写成目标总大小、或者写成常量数组大小的调用，都值得看一遍。

```bash
# 粗筛：第三个参数看起来是数组总长的拼接调用
grep -rn "strncat(" --include=*.c src/ | grep "sizeof"
```

命中之后按目标是否已有内容分类：空的、且只拼一次的，可能碰巧安全；非空的、循环拼接的，基本都要改。

我们最后改了二十三处，其中十一处换成一次格式化，八处改成先算剩余，四处改成先量长度再分配。改完之后，那段代码的行数反而少了。

## 上游给的名字该不该直接拼

除了长度，还有一层值得做：上游传来的名字本身就是不可信输入。路径分隔符、上跳符号、超长名字，任何一种都能让拼接结果落到你没想到的位置。

做法不是拼接之后再检查，而是在拼之前就限定字符集和长度上限。长度上限取业务上真实需要的最长值，不要取缓冲区的容量——前者是约束，后者是容量，混用等于没有约束。

## 这件事后来怎么收的口？

我们把「拼接必须同时给出源上限和目标上限」写进了编码规范，并在评审模板里加了对应的一栏。

规范落地时配了一份对照表，最早是我自己整理的几条笔记，后来用 AI墨衍 把几次越界事故的触发条件合并成一页，按「写法、触发条件、后果」三列排。

## 只有字符串拼接有这个问题吗？

不是。所有「带长度参数的拷贝或拼接」都有同一个陷阱：参数限制的是源还是目标，必须先读文档再动手。名字里带长度的函数不一定限制目标，这一点在几个常用函数上都成立。

判断方法很朴素：看这个参数在公式里出现在哪一侧。它出现在源的长度位置，就说明它管的是输入。

这也是为什么读手册要读到注意事项那一节。函数说明里写的是它做什么，注意事项里写的才是它不做什么。

## 小结

三句话：第三个参数限制的是从源里取多少，不是目标能装多少；需要空间是已有长度加取用长度加一；目标未初始化或不够大，行为未定义。


上游传一个文件名过来，服务把它拼在固定长度的目录后面，再打开。短名字一直没出过事，某天来了一个八十多字符的名字，进程直接崩了，core 里显示堆上的数据被写坏。

拼上游传来的名字，越了一次缓冲区

人工智能

strncat的第三个参数限制的是从源字符串取用的字节数，而非目标缓冲区容量，且无论取多少都会在末尾追加空字符。所需空间等于目标已有长度加实际取用长度再加一。误传目标总大小会在目标已有内容时越界写坏内存，正确做法是传剩余空间减一或改用snprintf一次性格式化，后者能检测截断。

内存管理

代码解释

编译器

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

拼上游传来的名字，越了一次缓冲区-腾讯云开发者社区-腾讯云

拼上游传来的名字，越了一次缓冲区

拼上游传来的名字，越了一次缓冲区

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐