使用魔法调试值（例如 0xDEADBEEF）作为文字到底有什么危险？

Question

不用说，使用硬编码的十六进制文字指针是一场灾难：

int *i = 0xDEADBEEF;
// god knows if that location is available

但是，使用十六进制文字作为变量值到底有什么危险？

int i = 0xDEADBEEF;
// what can go wrong?

如果这些值由于在各种调试场景中使用而确实“危险” a>，那么这意味着即使我不使用这些文字，任何在运行时碰巧偶然发现这些值之一的程序都可能崩溃。

有人愿意解释使用十六进制文字的真正危险吗？

---

编辑：只是为了澄清一下，我并不是指源代码中常量的一般使用。我特别讨论的是使用十六进制值时可能出现的调试场景问题，并以 0xDEADBEEF 为例。

Answer 1

使用十六进制文字并不比任何其他类型的文字更危险。

如果您的调试会话最终将数据作为代码执行，而不是您想要的，那么您无论如何都会陷入痛苦的世界。

当然，存在正常的“神奇值”与“命名良好的常量”代码气味/清洁问题，但这并不是我认为您正在谈论的那种危险。

Answer 2

除了少数例外，没有什么是“恒定的”。

我们更喜欢称它们为“慢变量”——它们的值变化如此之慢，以至于我们不介意重新编译来更改它们。

但是，我们不希望在应用程序或测试脚本中出现许多 0x07 实例，其中每个实例都有不同的含义。

我们希望为每个常量贴上标签，使其含义完全明确。

if( x == 7 )

上述语句中的“7”是什么意思？ 吗

d = y / 7;

它和“7”的意思一样

？测试用例是一个稍微不同的问题。我们不需要对数字文字的每个实例进行广泛、仔细的管理。相反，我们需要文档。

在某种程度上，我们可以通过在代码中包含一点提示来解释“7”的来源。

assertEquals( 7, someFunction(3,4), "Expected 7, see paragraph 7 of use case 7" );

“常数”应该只被陈述和命名一次。

单元测试中的“结果”与常量不同，在解释它的来源时需要小心一些。

Answer 3

十六进制文字与十进制文字（如 1）没有什么不同。值的任何特殊意义都取决于特定程序的上下文。

Answer 4

我相信今天早些时候在 IP 地址格式化问题中提出的问题与一般的十六进制文字的使用无关，而是与 0xDEADBEEF 的具体使用有关。至少，我是这么读的。

特别是使用 0xDEADBEEF 时存在一个问题，尽管在我看来这是一个很小的问题。问题是许多调试器和运行时系统已经将这个特定值作为标记值来指示未分配的堆、堆栈上的错误指针等。

我不记得哪个调试和运行时了系统使用这个特定的值，但多年来我已经多次看到它以这种方式使用。如果您在其中一种环境中进行调试，则代码中 0xDEADBEEF 常量的存在将与未分配的 RAM 或其他内容中的值无法区分，因此最多您不会获得有用的 RAM 转储，最坏的情况下您会收到警告来自调试器。

无论如何，这就是我认为最初的评论者告诉你这不利于“在各种调试场景中使用”时的意思。

Answer 5

您没有理由不将 0xdeadbeef 分配给变量。

但是，那些尝试分配十进制 3735928559 或八进制 33653337357 或最糟糕的是：二进制 11011110101011011011111011101111 的程序员将遭遇不幸。

Answer 6

Big Endian 还是 Little Endian？

一种危险是当常量被分配给具有不同大小成员的数组或结构时；编译器或机器（包括 JVM 与 CLR）的字节序会影响字节的顺序。

当然，这个问题也适用于非常量值。

这是一个无可否认的人为的例子。最后一行之后 buffer[0] 的值是多少？

const int TEST[] = { 0x01BADA55,  0xDEADBEEF };
char buffer[BUFSZ];

memcpy( buffer, (void*)TEST, sizeof(TEST));

Answer 7

我认为将其用作值没有任何问题。毕竟它只是一个数字。

Answer 8

在正确的上下文中使用指针的硬编码十六进制值（如您的第一个示例）没有危险。特别是，在进行非常低级的硬件开发时，这是访问内存映射寄存器的方式。 （例如，尽管最好用 #define 为它们命名。）但在应用程序级别，您不需要执行这样的分配。

Answer 9

我用咖啡宝贝
我以前没有见过任何调试器使用过它。

Answer 10

int *i = 0xDEADBEEF;
// god knows if that location is available

int i = 0xDEADBEEF;
// what can go wrong?

我在这两种情况下看到的危险是相同的：您创建了一个没有直接上下文的标志值。在这两种情况下，i 都无法让我知道 100、1000 或 10000 行中存在与其关联的潜在关键标志值。你植入的是一个地雷错误，如果我不记得在每一个可能的使用中检查它，我可能会面临一个可怕的调试问题。现在，每次使用 i 都必须如下所示：

if (i != 0xDEADBEEF) { // Curse the original designer to oblivion
    // Actual useful work goes here
}

对需要在代码中使用 i 的所有 7000 个实例重复上述操作。

现在，为什么上面的情况比这个更糟糕？

if (isIProperlyInitialized()) { // Which could just be a boolean
    // Actual useful work goes here
}

至少，我可以发现几个关键问题：

1. 拼写：我是一个糟糕的打字员。您在代码审查中如何容易地发现 0xDAEDBEEF？或者0xDEADBEFF？另一方面，我知道我的编译将立即在 isIProperlyInitialized() 上崩溃（在此插入强制性的 s 与 z 辩论）。
2. 意义的暴露。您没有试图在代码中隐藏您的标志，而是有意创建了一个其余代码可以看到的方法。
3. 耦合机会。指针或引用完全有可能连接到松散定义的缓存。可以重载初始化检查，首先检查该值是否在缓存中，然后尝试将其带回到缓存中，如果全部失败，则返回 false。

简而言之，编写您真正需要的代码就像创建神秘的魔法值一样容易。未来的代码维护者（很可能就是你）会感谢你。