为什么打开 char 值没有达到 case 0xC2？

Question

在下面的代码中发现了一个错误，它解析 C-string 并且应该检测 UTF8 字符：

char* pTmp = ...;
...
switch (*pTmp)
{
    case 'o':
    {
        ...     // works fine
        break;
    }   
    case 0xC2:
    {
        ...     // never gets triggered
        break;
    }
}

但是case 0xC2: 永远不会被触发。

我的假设是 0xC2 被认为是 int，因此是 194，它大于 char 数据类型的最大值 127。所以-62 != 194

或者可能这里发生了一些溢出或整数提升。

写switch ((unsigned char)*pTmp) 解决了这个问题。

但我想澄清一下这里到底发生了什么以及应用了哪些规则。

我也愿意更改标题，只是没有更好的想法。

Answer 1

我在添加 -Wall here 时得到这个

warning: case label value exceeds maximum value for type [-Wswitch-outside-range]
   14 |             case 0xC2:

所以是的，你的推理是正确的。

Answer 2

char 签名了吗？

如果char 与signed char 或unsinged char 具有相同的范围，则具体实现。在 OP 的情况下，char 的范围是 [-128 ... 127]，因此 case 0xC2: 永远不会匹配。

---

但我想澄清一下这里到底发生了什么以及应用了哪些规则。

C 标准库字符串函数有许多参数是char *，但这些库函数在内部的行为就好像它们指向unsigned char 数据

对于本子条款中的所有函数，每个字符都应被解释为好像它具有 unsigned char 类型（因此每个可能的对象表示都是有效的并且具有不同的值）。 C17dr § 7.24.1 3

为了匹配，OP 的代码也应该这样做。这样做还将允许*upTmp 可能匹配0xC2。

char* pTmp = ...;
unsigned char* upTmp = ( unsigned char*) pTmp;

switch (*upTmp)

   case 0xC2:

---

替代使用十六进制常量0xC2，使用字符常量：'\xC2' 匹配char 的范围。 @Eric Postpischil.

---

[迂腐]

“switch ((unsigned char)*pTmp) 解决了这个问题。” - 够近了。

此“修复”适用于签名为 char 的 2 的补码，以及当定义的实现 char 匹配 unsigned char 时。

对于其余所有但不存在的情况，其中char 是带符号的而不是 2 的补码，修复是错误的，因为字符应该通过 unsigned char * 访问，否则使用错误的值。

switch (*(unsigned char *)pTmp) 在所有情况下都能正常工作。