使用 char 参数从 <cctype> 调用函数是否安全？

Question

C 编程语言说来自<ctype.h> 的函数遵循一个共同的要求：

ISO C99，7.4p1：

在所有情况下，参数都是int，其值应表示为unsigned char，或应等于宏EOF 的值。如果参数有任何其他值，则行为未定义。

这意味着下面的代码是不安全的：

int upper(const char *s, size_t index) {
  return toupper(s[index]);
}

如果此代码在char 具有与signed char 相同的值空间并且字符串中存在具有负值的字符的实现上执行，则此代码将调用未定义的行为。正确的版本是：

int upper(const char *s, size_t index) {
  return toupper((unsigned char) s[index]);
}

尽管如此，我看到许多 C++ 示例并不关心这种未定义行为的可能性。那么C++标准中有什么东西可以保证上面的代码不会导致未定义的行为，还是说所有的例子都是错的？

[附加关键字：ctype cctype isalnum isalpha isblank iscntrl isdigit isgraph islowwer isprint ispunct isspace isupper isxdigit tolower]

Answer 1

不管怎样，Solaris Studio 编译器（使用stlport4）就是这样一种编译器套件，在这里会产生意想不到的结果。编译并运行：

#include <stdio.h>
#include <cctype>

int main() {
    char ch = '\xa1'; // '¡' in latin-1 locales + UTF-8
    printf("is whitespace: %i\n", std::isspace(ch));
    return 0;
}

给我：

kevin@solaris:~/scratch
$ CC -library=stlport4 whitespace.cpp && ./a.out 
is whitespace: 8

供参考：

$ CC -V
CC: Studio 12.5 Sun C++ 5.14 SunOS_i386 2016/05/31

当然，这种行为在 C++ 标准中有所记载，但绝对令人惊讶。

---

编辑：由于有人指出，由于整数溢出，上述版本在尝试分配 char ch = '\xa1' 时包含未定义的行为，所以这里有一个版本可以避免这种情况并仍然保留相同的输出：

#include <stdio.h>
#include <cctype>

int main() {
    char ch = -95;
    printf("is whitespace: %i\n", std::isspace(ch));
    return 0;
}

在我的 Solaris VM 上仍然打印 8：

kevin@solaris:~/scratch
$ CC -library=stlport4 whitespace.cpp && ./a.out 
is whitespace: 8

---

编辑 2：这里的程序可能看起来很正常，但由于 UB 在使用 std::isspace() 时会产生意想不到的结果：

#include <cstdio>
#include <cstring>
#include <cctype>

static int count_whitespace(const char* str, int n) {
    int count = 0;
    for (int i = 0; i < n; i++)
        if (std::isspace(str[i]))  // oops!
            count += 1;
    return count;
}

int main() {
    const char* batman = "I am batman\xa1";
    int n = std::strlen(batman);
    std::printf("%i\n", count_whitespace(batman, n));
    return 0;
}

而且，在我的 Solaris 机器上：

kevin@solaris:~/scratch
$ CC whitespace.cpp && ./a.out
3

请注意，根据您如何置换此程序，您可能会得到两个空白字符的预期结果；也就是说，几乎可以肯定会有一些编译器优化利用这个 UB 更快地给你错误的结果。

例如，如果您尝试通过在字符串中搜索（非多字节）空白字符来标记 UTF-8 字符串，您可以想象这会咬到您的脸。这样的程序在将str[i] 转换为unsigned char 时会正确运行。

Answer 2

有时大多数人都错了。我想就是这样。话虽如此，没有什么可以阻止标准库实现者定义大多数人期望的行为。所以也许这就是大多数人不关心的原因，因为他们实际上从未见过由这个错误导致的错误。

Answer 3

char 类型背后的历史是它最初是用于描述 7 位 ASCII 字符的类型。同时，C 缺乏单独的 8 位整数类型。所以在八十年代的准标准时代，一些编译器使char 无符号 - 因为在符号表中使用负索引没有意义，而其他编译器使char 有符号，以使其与所有其他整数类型。

到了标准化 C 的时候，两个版本都存在。不幸的是，委员会决定让它保持这种状态，将决定权留给编译器。相反，他们添加了另外两种类型：signed char 和 unsigned char。 signed char 是有符号整数类型的一部分，unsigned char 是无符号整数类型的一部分，char 两者都不是，尽管它必须具有与 signed char 或 unsigned char 相同的表示形式。 （这在 C11 6.2.5 中都有描述）

值得注意的是，char 在所有已知实现中都只有 8 位，除了一些使用 16 位字节的奇异 DSP。当使用“扩展”符号表时，要么实现从 7 位字符更改为 8 位字符，要么使用 wchar_t。请注意，wchar_t 从一开始就在 C 语言中，因此假设 char 在某些时候用于 UTF8 之类的东西可能是不正确的（尽管理论上是可能的）。

现在，如果 char 已签名，并且您在其中存储了一个大于 CHAR_MAX 或小于 CHAR_MIN 的值，则按照 C11 6.5 §5 调用未定义的行为。时期。因此，如果您有一个 char 数组并且其中的任何项目都违反了类型边界，那么您已经存在未定义的行为。尽管字符类型必须捕获表示，但未定义的行为可能会导致代码在其他方面出现错误行为，例如不正确的优化。

ctype.h 函数允许 EOF 作为参数，但在其他方面应该表现得好像使用字符类型一样，即使参数是 int 以允许 EOF。 7.4 §1 中的文字主要是说“如果你将一些随机的int 传递给这个函数，它既不是与 char 相同的表示形式，也不是 EOF，那么行为是未定义的”。

但是如果你传递一个char，你已经调用了有符号整数上溢/下溢，你甚至在调用函数之前就已经有未定义的行为——这与 ctype.h 函数或任何其他函数无关。因此，您对发布的“上层”函数不安全的假设是不正确的 - 此代码与使用 char 类型的任何其他代码没有什么不同。

由 7.4 中引用的 ctype.h 限制导致的未定义行为示例宁可类似于 toupper(666)。