越界写入并非总会触发错误，为何malloc(24)才报错而非malloc(28)？

这个问题的核心其实是**未定义行为（Undefined Behavior）**的典型表现——越界写入并不是一定会立刻触发错误，它的后果完全取决于内存布局、分配器实现等随机因素，这也是这类内存错误最危险的地方。下面拆解具体原因：

1. 内存分配器的“隐形缓冲区”策略 #

大多数malloc实现不会严格只分配你请求的字节数，为了满足内存对齐要求（比如按8/16字节对齐）或者存储管理元数据（比如记录块大小、链表指针的头部信息），会把请求的大小向上取整到某个最小单元：

• 当你调用malloc(25)时，分配器可能实际给了你32字节的内存块（刚好满足8字节对齐的最小上限），这时候你的越界写入（总长度远超30）还在分配的内存范围内，自然不会触发错误；
• 而malloc(24)刚好是8字节对齐的边界值，分配器只会给你24字节的内存，此时越界写入直接覆盖了分配器用于管理堆内存的元数据（比如下一个空闲块的指针），后续执行free或再次malloc时，分配器读取被破坏的元数据，就会触发崩溃。

2. 内存布局的随机性 #

就算分配器给的空间刚好够，越界写入是否报错还取决于你覆盖的内容：

• 如果只是覆盖了堆里未被使用的空闲内存区域，程序可能暂时“正常”运行；
• 但如果覆盖了分配器的链表结构、其他变量的内存，或者后续会被用到的数据，就会立刻或在某个后续操作中崩溃。你测试到25字节还正常，只是刚好越界的部分没碰到底层的敏感数据而已。

3. 未定义行为的本质 #

C标准明确规定，越界访问内存属于未定义行为——编译器和运行时完全没有义务给你报错，它可能表现为“正常运行”、崩溃、数据损坏，甚至在优化后出现完全不可预料的结果。你不能用“测试多少次正常”来判断代码是安全的，今天在你的机器上25字节没问题，换个系统、换个编译器版本，可能10字节就崩溃了。

解决建议：严格控制写入长度 #

要彻底避免这类问题，必须保证写入的字节数不超过分配的内存大小：

• 使用snprintf代替strcpy/strcat，它可以指定最大写入字节数，从根源上避免越界：

  // buffer是分配的内存，allocated_size是分配的字节数
  snprintf(buffer, allocated_size, "%s%s", loglevs, des);
  

• 提前计算需要的总长度，再分配足够的内存：

  size_t total_len = strlen(loglevs) + strlen(des) + 1; // +1是字符串结束符'\0'
  char* buffer = malloc(total_len);
  if (buffer != NULL) {
      strcpy(buffer, loglevs);
      strcat(buffer, des);
  }
  

内容的提问来源于stack exchange，提问作者geohei