C 风格字符串缺陷及改进

gets() 的函数原型如下：

char * gets(char *);

它的功能是：从输入缓冲区中读取一个字符串存储到字符指针变量所指向的内存空间，并删除换行符。

gets() 没有限制它的读取长度，非常容易溢出。如果溢出，多出来的字符将被写入到堆栈中，这就覆盖了堆栈原先的内容，破坏一个或多个不相关变量的值。

在 C11 标准中，gets() 函数被废除，以 gets_s() 取而代之。

fgets() 的函数原型为：

char * fgets(char *str, int n, FILE *stream);

fgets() 从指定的流中读取一行，并将内容存储在字符数组 str 中，当读取 (n-1) 个字符时，或者读取到换行符时，或者到达文件末尾时，它会停止。

相比于 gets()，fgets() 无疑安全了很多，它的第二个参数限制了读取字符个数，可以确保缓冲区的安全。它对换行符的保留体现了与 gets() 的不同之处。

对于 bString 文档中提出的问题，我使用下面的代码进行了实验：

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
    FILE * fp = NULL;

    if ((fp = fopen("1.txt", "w")) == NULL) exit(1);

    char a[10] = { '\0' };
    a[0] = a[1] = 'y';
    for (int i = 0; i < 10; i++) fputc(a[i], fp);
    fputc('\n', fp);
    fclose(fp);

    if ((fp = fopen("1.txt", "r")) == NULL) exit(2);

    char b[20];
    for (int i = 0; i < 20; i++) b[i] = 1;

    fgets(b, 20, fp);

    for (int i = 0; i < 20; i++) printf("%d ", b[i]);

    fclose(fp);

    return 0;
}

输出结果为 121 121 0 0 0 0 0 0 0 0 10 0 1 1 1 1 1 1 1 1 。作者的原话如下：

fgets has the unusual semantic of ignoring '\0's that occur before '\n's are consumed.

这句话的意思我不是太明白，但有一个问题是显而易见的：这样一来，换行符肯定是不可见的，换行符前面的除了第一个空字符之外的其他空字符也是不可见的。

该函数的原型为：

char * strncpy ( char * destination, const char * source, size_t num );

参考 www.cplusplus.com[1] 可以得到以下类容： No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered a null terminated C string (reading it as such would overflow). 翻译过来即：如果源字符串的长度大于参数 num 的值，那么空字符不会被加到目标字符串的结尾。因此，在这种情况下，目标字符串不应该被当作以空字符结尾的 C 字符串。

这显然是一个坑，如果把得到的目标字符串直接当作正常字符串处理，将很可能会导致程序的崩溃。

将 NULL 或者其他不合法的字符串地址传递给字符串处理函数会导致对内存的非法操作，将直接导致程序的崩溃。这个问题不是 C 库中的字符串函数所独有的。但是，这些字符串函数并没有通过返回值或者其他方式来反馈这些错误的出现，这些错误是没有检查的。除非使用调试器，否则我们只会看到程序的崩溃，而不知道具体的错误信息。

例如：

strcpy (p = malloc (13 * sizeof (char)), "Hello,");
strcat (p, " World");

这种写法非常的不安全，p 可能因为内存耗尽而得到一个空指针值，从而直接引起非法内存访问。

当向函数传递两个参数，其中一个指向的数据结构与另一个在内存上重叠时，重叠问题便出现了。

这对于只读函数来说不是个问题，但向内存中进行写入操作的函数会因此而发生错误。这在 C 标准库中是一个普遍的问题，尤其是在字符串库中。

C 的字符串是一个字符接着一个字符的连续形式，在某些场景下实现重叠安全是很容易的。但是 C 的字符串函数一般是不会进行重叠检测的，因此随便举出由重叠而导致的未定义行为的例子是非常容易的。

最简单的例子，例如：

char a[20] = "Hello";
strcat(a, a);
puts(a);

编译并运行，你并不会看到 HelloHello，而是程序的崩溃退出。strcat 的第二参数表达的源字符串要保证在函数执行期间保持不变，这样才能正确运行。而在上面的例子中，第一参数恰恰指向需要改变的空间。既要不变，又需要改变，这就像是拉着自己的头发把自己提起来一样，结果显然是不可预料的。

有关多线程有一个笑话：“之前我有一个问题，使用了多线程之后，现在两个题问我有”。文档作者提到 strtok() 因为会对字符串参数进行修改而不具有线程安全性，这可能说明对字符串进行修改的 C 库中的字符串函数都不具有线程安全性。

C 中没有真正的字符串类型，它连像是 fopen/fclose 的管理机制都没有提供，对字符串的操作不可避免的会涉及到手动内存管理，而这正是 C 程序中许多耗时 bug 的主要来源。

我至少可以这样总结：C 风格字符串没有线程安全，没有内存管理机制，字符串函数操作没有错误检查，函数接口设计不合理，函数功能杂乱，等等…… 它唯一的优点似乎就是速度了。这些缺陷很大程度上来自历史原因，毕竟 C 语言出生的时候还没有多线程这种东西。在这些函数大量使用的时候， C 语言还没有一个严谨统一的标准。 The C Standard Library 中这样写到：

大多数人可能不会想到这些函数有一些设计缺陷。<string.h> 中声明的函数不是共同设计努力的结果。相反，它们是由很多程序员在很长的时间力做出的贡献积累起来的。到 C 标准化开始的时候，“修整”他们已经太晚了，太多的程序对函数的行为已经有了明确的定义。

如果不以相当谨慎的态度来面对这些函数的话，在编程的过程中很容易一脚一个坑。顾虑太多会使得心智负担太重，这对于编程效率会带来非常大的影响。相比于直接使用这些老旧的函数，使用更新更安全的库无疑是明智之举。

正如 The Standard C Library 中所言，<string.h> 中的函数接口并不是精心设计的，使用有明显缺陷的函数会增加程序出现 bug 的可能性。

bString 在 bsafe.h 中列出了几个“危险”的函数，它们分别是 strcpy()，strcat()，gets()，strncpy()，strncat()，strtok() 和 strdup()。其中的几个上面已经有过分析。

相比于 <string.h> 近乎于裸奔的字符串函数，另外的一些函数库在安全性上要大大的优于它。在这里我对 Microsoft 的 strsafe 和上文中提到的 bstring 进行简单的介绍，并分析它们相对于 C 库字符串函数的优点。

struct tagbstring {
    int mlen;
    int slen;
    unsigned char * data;
};
typedef struct tagbstring * bstring;