((a + (b & 255)) & 255) 和 ((a + b) & 255) 一样吗？

Question

我正在浏览一些 C++ 代码，发现如下内容：

(a + (b & 255)) & 255

双重AND惹恼了我，所以我想到了：

(a + b) & 255

（a 和 b 是 32 位无符号整数）

我很快写了一个测试脚本（JS）来证实我的理论：

for (var i = 0; i < 100; i++) {
    var a = Math.ceil(Math.random() * 0xFFFF),
        b = Math.ceil(Math.random() * 0xFFFF);

    var expr1 = (a + (b & 255)) & 255,
        expr2 = (a + b) & 255;

    if (expr1 != expr2) {
        console.log("Numbers " + a + " and " + b + " mismatch!");
        break;
    }
}

虽然脚本证实了我的假设（两个操作相等），但我仍然不相信它，因为 1) random 和 2) 我不是数学家，I have no idea what am I doing。

另外，对于 Lisp-y 标题感到抱歉。随意编辑它。

Answer 1

它们是一样的。这是一个证明：

先记下身份(A + B) mod C = (A mod C + B mod C) mod C

让我们通过将a & 255 视为a % 256 的替代来重申这个问题。这是真的，因为a 是未签名的。

所以(a + (b & 255)) & 255 是(a + (b % 256)) % 256

这与(a % 256 + b % 256 % 256) % 256 相同（我已经应用了上述标识：请注意mod 和% 对于无符号类型是等效的。）

这简化为(a % 256 + b % 256) % 256，它变成(a + b) % 256（重新应用身份）。然后你可以把按位运算符放回去给

(a + b) & 255

完成证明。

Answer 2

是的，(a + b) & 255 很好。

还记得学校里的加法吗？您逐位添加数字，并将进位值添加到下一列数字。后面的（更重要的）数字列无法影响已处理的列。因此，如果您仅将结果中的数字归零，或者也将参数中的第一个数字归零，这并没有什么不同。

---

上述情况并不总是正确的，C++ 标准允许实现会破坏这一点。

这样的 Deathstation 9000 :-) 必须使用 33 位 int，如果 OP 意味着 unsigned short 和“32 位无符号整数”。如果指的是unsigned int，则DS9K 必须使用32 位int，以及带有填充位的32 位unsigned int。 （根据 §3.9.1/3，无符号整数的大小必须与其有符号整数相同，并且在 §3.9.1/1 中允许使用填充位。）大小和填充位的其他组合也可以。

据我所知，这是打破它的唯一方法，因为：

• 整数表示必须使用“纯二进制”编码方案（第 3.9.1/7 节和脚注），除填充位和符号位之外的所有位必须贡献值 2ⁿ
• 仅当int 可以表示源类型的所有值（第 4.5/1 节）时才允许进行 int 提升，因此int 必须至少有 32 位参与该值，外加一个符号位。李>
• int 的值位（不包括符号位）不能超过 32 个，否则加法不会溢出。

Answer 3

在无符号数的位置加法、减法和乘法以产生无符号结果时，输入的较高有效数字不会影响结果的较低有效数字。这适用于二进制算术，就像它适用于十进制算术一样。它也适用于“二进制补码”有符号算术，但不适用于符号幅度有符号算术。

但是，在从二进制算术中获取规则并将它们应用于 C 时，我们必须小心（我相信 C++ 在这些东西上与 C 有相同的规则，但我不是 100% 确定），因为 C 算术有一些神秘的规则可以绊倒我们。 C 中的无符号算术遵循简单的二进制环绕规则，但有符号算术溢出是未定义的行为。更糟糕的是，在某些情况下，C 会自动将无符号类型“提升”为 (signed) int。

C 中未定义的行为可能特别隐蔽。愚蠢的编译器（或低优化级别的编译器）可能会根据您对二进制算术的理解执行您期望的操作，而优化的编译器可能会以奇怪的方式破坏您的代码。

---

所以回到问题中的公式，等价取决于操作数类型。

如果它们是大小大于或等于int 的大小的无符号整数，则加法运算符的溢出行为被明确定义为简单的二进制回绕。我们是否在加法运算之前屏蔽掉一个操作数的高 24 位对结果的低位没有影响。

如果它们是大小小于int 的无符号整数，那么它们将被提升为（有符号）int。有符号整数的溢出是未定义的行为，但至少在我遇到的每个平台上，不同整数类型之间的大小差异足够大，以至于两个提升值的单次相加不会导致溢出。所以我们可以再次回到简单的二进制算术参数来认为语句等效。

如果它们是大小小于 int 的有符号整数，则不会再次发生溢出，并且在二进制补码实现中，我们可以依靠标准二进制算术参数来说明它们是等价的。在符号大小或补充实现上，它们不会是等价的。

OTOH 如果 a 和 b 是大小大于或等于 int 大小的有符号整数，那么即使在二进制补码实现中，也存在一个语句定义明确而另一个语句未定义的情况行为。

Answer 4

相同假设没有溢出。这两个版本都不能真正避免溢出，但 double 和版本更能抵抗溢出。我不知道在这种情况下溢出是一个问题的系统，但我可以看到作者这样做，以防万一。

Answer 5

您已经有了聪明的答案：无符号算术是模算术，因此结果将成立，您可以用数学方法证明...

---

不过，关于计算机的一个很酷的事情是计算机速度很快。事实上，它们的速度如此之快，以至于可以在合理的时间内枚举所有 32 位的有效组合（不要尝试使用 64 位）。

所以，就你而言，我个人喜欢把它扔到电脑上；我说服自己程序正确所花费的时间比说服自己比数学证明正确所花费的时间更少并且我没有监督规范中的细节^1支持>：

#include <iostream>
#include <limits>

int main() {
    std::uint64_t const MAX = std::uint64_t(1) << 32;
    for (std::uint64_t i = 0; i < MAX; ++i) {
        for (std::uint64_t j = 0; j < MAX; ++j) {
            std::uint32_t const a = static_cast<std::uint32_t>(i);
            std::uint32_t const b = static_cast<std::uint32_t>(j);

            auto const champion = (a + (b & 255)) & 255;
            auto const challenger = (a + b) & 255;

            if (champion == challenger) { continue; }

            std::cout << "a: " << a << ", b: " << b << ", champion: " << champion << ", challenger: " << challenger << "\n";
            return 1;
        }
    }

    std::cout << "Equality holds\n";
    return 0;
}

这会枚举 32 位空间中 a 和 b 的所有可能值，并检查相等性是否成立。如果没有，它会打印不起作用的案例，您可以将其用作健全性检查。

并且，according to Clang：平等成立。

此外，鉴于算术规则与位宽无关（高于int 位宽），此等式将适用于任何 32 位或更多位的无符号整数类型，包括 64 位和 128 位。

注意：编译器如何在合理的时间范围内枚举所有 64 位模式？这不可以。循环被优化了。否则我们都会在执行终止之前死去。

---

我最初只证明了 16 位无符号整数；不幸的是，C++ 是一种疯狂的语言，其中小整数（比int 更小的位宽）首先转换为int。

#include <iostream>

int main() {
    unsigned const MAX = 65536;
    for (unsigned i = 0; i < MAX; ++i) {
        for (unsigned j = 0; j < MAX; ++j) {
            std::uint16_t const a = static_cast<std::uint16_t>(i);
            std::uint16_t const b = static_cast<std::uint16_t>(j);

            auto const champion = (a + (b & 255)) & 255;
            auto const challenger = (a + b) & 255;

            if (champion == challenger) { continue; }

            std::cout << "a: " << a << ", b: " << b << ", champion: "
                      << champion << ", challenger: " << challenger << "\n";
            return 1;
        }
    }

    std::cout << "Equality holds\n";
    return 0;
}

再一次，according to Clang：平等成立。

好吧，你去吧:)

---

¹当然，如果一个程序无意中触发了未定义行为，那也证明不了多少。

Answer 6

快速回答是：两个表达式是等价的

• 由于a 和b 是32 位无符号整数，即使发生溢出，结果也是相同的。无符号算术保证了这一点：不能用得到的无符号整数类型表示的结果以比结果类型可以表示的最大值大一的数字为模减少。

长答案是：没有已知的平台在这些表达方式上会有所不同，但标准不保证这一点，因为积分提升的规则。

• 如果 a 和 b（无符号 32 位整数）的类型比 int 的等级更高，则计算为无符号，模 2³²，对于a 和b 的所有值，这两个表达式都会产生相同的定义结果。

• 相反，如果a 和b 的类型小于int，则两者都提升为int，并使用有符号算术执行计算，其中溢出会调用未定义的行为。

  • 如果int至少有33个值位，以上表达式都不会溢出，所以结果定义完美，两个表达式的值相同。

  • 如果 int 正好有 32 个值位，计算 可能 对 both 表达式溢出，例如值 a=0xFFFFFFFF 和 b=1 会导致两个表达式中的溢出。为了避免这种情况，你需要写((a & 255) + (b & 255)) & 255。

• 好消息是没有这样的平台¹。

---

¹ 更准确地说，不存在这样的真实平台，但可以配置DS9K 来展示这样的行为并仍然符合C 标准。

Answer 7

引理：a & 255 == a % 256 表示未签名的a。

未签名的a 可以重写为m * 0x100 + b 一些未签名的m、b、0 <= b < 0xff、0 <= m <= 0xffffff。从这两个定义来看，a & 255 == b == a % 256。

另外，我们需要：

• 分配属性：(a + b) mod n = [(a mod n) + (b mod n)] mod n
• 无符号加法的定义，数学上：(a + b) ==> (a + b) % (2 ^ 32)

因此：

(a + (b & 255)) & 255 = ((a + (b & 255)) % (2^32)) & 255      // def'n of addition
                      = ((a + (b % 256)) % (2^32)) % 256      // lemma
                      = (a + (b % 256)) % 256                 // because 256 divides (2^32)
                      = ((a % 256) + (b % 256 % 256)) % 256   // Distributive
                      = ((a % 256) + (b % 256)) % 256         // a mod n mod n = a mod n
                      = (a + b) % 256                         // Distributive again
                      = (a + b) & 255                         // lemma

所以是的，这是真的。对于 32 位无符号整数。

---

其他整数类型呢？

• 对于 64 位无符号整数，上述所有方法同样适用，只需将 2^64 替换为 2^32。
• 对于 8 位和 16 位无符号整数，加法涉及升级到 int。这个int 在任何这些操作中绝对不会溢出或为负，所以它们都保持有效。
• 对于有符号整数，如果a+b 或a+(b&255) 溢出，这是未定义的行为。所以等式不成立——在某些情况下(a+b)&255 是未定义的行为，但(a+(b&255))&255 不是。

Answer 8

是的，你可以用算术证明它，但有一个更直观的答案。

添加时，每一位只影响比自己重要的那些；从来没有那些不那么重要的。

因此，无论您在加法之前对高位做什么都不会改变结果，只要您只保留比修改的最低位低的位。

Answer 9

证明是微不足道的，留给读者作为练习

但要真正将此作为答案合法化，您的第一行代码说取b** 的最后 8 位（b 的所有高位设置为零）并将其添加到 a 然后只取结果的最后 8 位，将所有高位设置为零。

第二行表示将a 和b 相加，并取最后8 位，所有高位为零。

只有最后 8 位在结果中是有效的。因此，只有最后 8 位在输入中是重要的。

** 最后 8 位 = 8 LSB

另外有趣的是，输出将等同于

char a = something;
char b = something;
return (unsigned int)(a + b);

如上所述，只有 8 个 LSB 是有效的，但结果是 unsigned int，所有其他位为零。 a + b 将溢出，产生预期的结果。