丢人的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.

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

这算什么BUG……C早就说过caller有责任保证buffer不overflow

....这也叫bug...你应该自己分配足够的空间来存下你的source,不然你以为你是在用java吗?
或者是VC++里的safe strcpy

看清楚了 是在dest里面填充n - strlen(src)的长度的0 这个非常低效率 而且容易出bug 实际上按我理解填个0就可以了.

填一堆的\0  效率上应该不会差多少，cpu指令好像有优化。不过越界的问题是个隐患

用sizeof(buf),代替 n,能减少越界问题

看了vc crt和gcc glibc的代码 循环填0的 这个buffer如果比较大的话 占用的开销比字符串本身要大的太多 所以在高级服务器里面 就要很谨慎使用这个函数。 很多服务器都是自己实现的这个函数，比如nginx, haproxy等。

就是不明白库的作者为什么这么设计 不符合c的习惯哦

内存越界倒不算什么问题 因为这实在太常见了 c本来就假设程序员是上帝的

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

话说回来 无论如何这不是bug 因为这种行为是符合定义的