2008-06-12

丢人的strncpy 语义理解错误

关键字: strncpy
今天发现strncpy使用上的一个古怪bug, 解决了是发现对strncpy的语义理解错误。

SYNOPSIS
#include <string.h>

char *strcpy(char *dest, const char *src);

char *strncpy(char *dest, const char *src, size_t n);

DESCRIPTION
The strcpy() function copies the string pointed to by src (including
the terminating '\0' character) to the array pointed to by dest. The
strings may not overlap, and the destination string dest must be large
enough to receive the copy.

The strncpy() function is similar, except that not more than n bytes of
src are copied. Thus, if there is no null byte among the first n bytes
of src, the result will not be null-terminated.

In the case where the length of src is less than that of n, the remain-
der of dest will be padded with null bytes.


请非常注意上面的红字:
1. 低效率的padding 因为常规情况下buffer要比实际的字符串大的多，所以无辜的填充。
2. 一旦不小心你的n 比 buffer的长度大 那就死惨了 内存狂越界写。
这种情况经常发生在你把buffer的长度改小了 但是后面的n没有相应地改。

相信很多人会遭受这个使用bug.
评论
lhyasia 2008-07-30
mryufeng 写道
to messup: 估计你这么理解 一用就错了


具体一点？ 我觉得messup说得挺好的
mryufeng 2008-06-26
原来这个还是有故事的，请看：

[程序]朱照远(Joshua Zhu) - 拜Igor神，拜Roberto神 说: (2008-06-26 15:23:38)
http://en.wikipedia.org/wiki/Strlcpy
[程序]朱照远(Joshua Zhu) - 拜Igor神，拜Roberto神 说: (2008-06-26 15:23:56)
原来是来自与OpenBSD
[程序]朱照远(Joshua Zhu) - 拜Igor神，拜Roberto神 说: (2008-06-26 15:27:01)
每个serious的网络程序都自己写一个或者copy一份
lavax 2008-06-26
看来你应该先看看谭爷爷的书
mryufeng 2008-06-19
to messup: 估计你这么理解 一用就错了
messup 2008-06-19
这个根本就不是bug，C程序员有责任对char*的结尾\0做控制，这个是程序员的责任。C里常做的事情就是从多个psrc中拷贝n个字符，拼接到pdest不同位置最后生成需要的字符串，最后一般都是自己加个结束0。
mryufeng 2008-06-16
问题是n家族的字符串函数是不是大家都了解语义 都不会用错？
jemyzhang 2008-06-16
归根结底还是出在程序员身上。
mryufeng 2008-06-12
这个不是指库的bug 库实现的很好 只是感觉程序员容易把它用错
seen 2008-06-12
内存越界倒不算什么问题 因为这实在太常见了 c本来就假设程序员是上帝的

不过“padded with null bytes”的确有点意思 没看出来有啥必要
毕竟c里面很多库函数，以及linux很多系统调用都不会主动帮你清空一块内存的

话说回来 无论如何这不是bug 因为这种行为是符合定义的
mryufeng 2008-06-12
就是不明白库的作者为什么这么设计 不符合c的习惯哦
mryufeng 2008-06-12
看了vc crt和gcc glibc的代码 循环填0的 这个buffer如果比较大的话 占用的开销比字符串本身要大的太多 所以在高级服务器里面 就要很谨慎使用这个函数。 很多服务器都是自己实现的这个函数，比如nginx, haproxy等。
coolmenu 2008-06-12
用sizeof(buf),代替 n,能减少越界问题
albertlee 2008-06-12
填一堆的\0 效率上应该不会差多少，cpu指令好像有优化。不过越界的问题是个隐患
mryufeng 2008-06-12
看清楚了 是在dest里面填充n - strlen(src)的长度的0 这个非常低效率 而且容易出bug 实际上按我理解填个0就可以了.
ray_linn 2008-06-12
....这也叫bug...你应该自己分配足够的空间来存下你的source,不然你以为你是在用java吗?
或者是VC++里的safe strcpy
刑天战士 2008-06-12
这算什么BUG……C早就说过caller有责任保证buffer不overflow
iunknown 2008-06-12
mryufeng 写道

2. 一旦不小心你的n 比 buffer的长度大 那就死惨了 内存狂越界写。
这种情况经常发生在你把buffer的长度改小了 但是后面的n没有相应地改。

相信很多人会遭受这个bug.



这里导致的问题通常在于 dest 没有以 \0 结尾，如果接下来对 dest 的处理依赖于这个结尾的 \0 ，就可能导致越界的读，这个的确会有人遇到。
但另一方面，这里提到越界写，这个是因为 n 和 dest 的实际长度不符，这个算不上是 strncpy 的 bug 吧，是写程序的人的问题。
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论