0xDEADBEEF 相当于 64 位开发？
用于 32 位系统（无论是 Linux、Mac OS 或 Windows、PowerPC 或 x86）我已经初始化了指针 否则将是未定义的（例如，它们不能立即 得到一个正确的值）像这样：（
int *pInt = reinterpret_cast<int *>(0xDEADBEEF);
为了节省打字并DRY右手侧面通常会 是一个常量，例如 BAD_PTR。）
如果 pInt 在获得正确值之前被取消引用，则 在大多数系统上它会立即崩溃（而不是 当某些内存被覆盖或消失时，很久以后就会崩溃 进入一个很长的循环）。
当然，行为取决于底层 硬件（从奇数中获取一个 4 字节整数 来自用户进程的地址 0xDEADBEEF 可能是完美的 有效），但对于所有的崩溃来说，崩溃都是 100% 可靠的。 到目前为止我开发的系统（Mac OS 68xxx、Mac OS PowerPC、Linux 红帽奔腾、Windows GUI 奔腾、Windows 控制台奔腾）。 例如在 PowerPC 上这是非法的（总线 错误）从奇数地址获取 4 字节整数。
在 64 位系统上，这个值有什么好处？
For C++ development for 32-bit systems (be it Linux, Mac OS or
Windows, PowerPC or x86) I have initialised pointers that
would otherwise be undefined (e.g. they can not immediately
get a proper value) like so:
int *pInt = reinterpret_cast<int *>(0xDEADBEEF);
(To save typing and being DRY the right-hand side would normally
be in a constant, e.g. BAD_PTR.)
If pInt is dereferenced before it gets a proper value then
it will crash immediately on most systems (instead of
crashing much later when some memory is overwritten or going
into a very long loop).
Of course the behavior is dependent on the underlying
hardware (getting a 4 byte integer from the odd
address 0xDEADBEEF from a user process may be perfectly
valid), but the crashing has been 100% reliable for all the
systems I have developed for so far (Mac OS 68xxx, Mac OS
PowerPC, Linux Redhat Pentium, Windows GUI Pentium, Windows
console Pentium). For instance on PowerPC it is illegal (bus
fault) to fetch a 4 byte integer from an odd address.
What is a good value for this on 64-bit systems?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
0xDEADBEEFBAADF00D可能有效。0xDEADBEEFBAADF00Dmight work.我没有给你一个好的选择，但这里有一个十六进制单词列表，你可以用于制作您的短语。
I don't have a good choice for you, but here's a list of hex words that you can use to make your phrase.
我认为两个 0xDEADBEEF 应该足够了。
Two 0xDEADBEEFs should be enough, I think..
我看到几个答案声称 NULL 是一个不错的选择，但我不同意。
NULL 通常用作函数的有效返回值。 它表示失败返回或未知值。 这与“未初始化的指针”的含义不同。
在代码上使用调试器并看到 NULL 会留下两种可能性：指针从未初始化或内存分配失败。
将未初始化的指针设置为 0xDEADBEEF 或 64 位等效值意味着 NULL 指针指示有意值。
I see several answers claiming NULL is a good choice, but I disagree.
NULL is often used as a valid return value from functions. It indicates a failure return or an unknown value. This is a different meaning than "uninitialized pointer."
Using a debugger on the code and seeing NULL would then leave two possibilities: the pointer was never initialized or it had failed a memory allocation.
Setting the uninitialized pointer to 0xDEADBEEF or the 64-bit equivalent means that a NULL pointer indicates an intentional value.
我假设您已经对 NULL 打了折扣（即没有类型转换的 0）。 这绝对是最安全的选择，因为理论上，有效的指针可以指向内存地址 0xDEADBEEF（或任何其他非 NULL 内存地址）。
I'm assuming you've already discounted NULL (i.e. 0 without the typecast). It's definitely the safest choice, as, in theory, a valid pointer could point to the memory address 0xDEADBEEF (Or any other non-NULL memory address).
一般来说，您编写的具体模式并不重要，重要的是您可以识别该模式以确定问题发生的位置。 碰巧的是，在 Linux 内核中，通常会选择这些地址，以便在取消引用地址时可以捕获它们。
查看 Linux 内核：include/linux/poison.h。 该文件包含许多不同内核子系统的不同毒害值。 没有一种毒药值是合适的。
此外，您还可以检查 Linux 内核源代码树中每个体系结构的包含文件，以获取有关特定体系结构上使用的内容的信息。
Generally it doesn't matter exactly what pattern you write, it matters that you can identify the pattern in order to determine where problems are occurring. It just so happens that in the Linux kernel these are often chosen so that they can be trapped if the addresses are dereferenced.
Have a look in the Linux kernel at include/linux/poison.h. This file contains different poison values for many different kernel subsystems. There is no one poison value that is appropriate.
Also, you might check per-architecture include files in the Linux kernel source tree for info on what is used on specific architectures.
大多数当前 64 位系统仅允许您使用地址空间的最低 248–252 位； 地址的高位必须全为零。 某些芯片（例如 amd64）还允许您使用最高 248–252。 这些范围之外的地址永远无法映射到可访问的内存； 硬件根本不允许这样做。
因此，我建议您使用接近 263 的值，该值与任何可能可用的空间相差甚远。 如果前四位十六进制数字是 7ff8，则该值将是双精度浮点 NaN，这很方便。 所以我建议的可爱的十六进制短语是 0x7FF8BADFBADFBADF。
顺便说一句，您确实不想使用接近 0 的值，因为这使得很难区分 NULL 的偏移量取消引用（例如，结构成员访问）和 NULL 的取消引用毒模式。
Most current 64-bit systems let you use only the lowest 248–252 bits of the address space; higher bits of the address must be all-zero. Some chips (e.g. amd64) also let you use the highest 248–252. Addresses outside these ranges cannot ever be mapped to accessible memory; the hardware simply won't allow it.
I therefore recommend you use a value close to 263, which is nowhere near either of the possibly-usable spaces. If the leading four hex digits are 7ff8, the value will be a double precision floating-point NaN, which is convenient. So my suggested cute hexadecimal phrase is 0x7FF8BADFBADFBADF.
By the way, you really don't want to use a value close to 0, because that makes it hard to tell an offset dereference of NULL — a structure member access, for instance — from a dereference of the poison pattern.
0xBADC0FFEE0DDF00D0xBADC0FFEE0DDF00D根据 Wikipedia，BADC0FFEE0DDF00D 在 IBM RS/6000 64 位系统上用于指示未初始化CPU寄存器。
According to Wikipedia, BADC0FFEE0DDF00D is used on IBM RS/6000 64-bit systems to indicate uninitialized CPU registers.
0x42可以在 32 位和 64 位上运行吗？ （它仍然应该触发崩溃，因为它足够接近 NULL 指针，并且考虑到它相当大，很可能您不会在结构指针为 NULL 的结构字段的常规取消引用中使用它）。0x42could work on both 32bit and 64bit ? (It should still trigger a crash since it is close enough to the NULL pointer, and given that it's rather large, chances are you would not have it within a regular dereference of a structure field with the structure pointer being NULL).当然，这取决于操作系统和环境。 我也不认为 0xDEADBEEF 在任意 32 位系统中一定是一个坏指针。
实际上，任何现代操作系统都应该对进程内存的前几页进行访问保护，因此 NULL 应该是一个很好的无效指针值。 足够方便，它已经为您预先定义了。
It depends on the OS and the environment, of course. I don't think 0xDEADBEEF is necessarily a bad pointer in an arbitrary 32-bit system, either.
Realistically, any modern OS should be access-protecting the first few pages of process memory, so NULL should be a good invalid pointer value. Conveniently enough, it's already pre-defined for you.
由于我工作的系统基本运行在x86_64平台上，所以我使用的值是：
原因是：
0xDEADBEEF在 32 位中已众所周知，因此 64 位中的0xDEADBEEFDEADBEEF只是更加“向后兼容”As the system I worked on basically runs on x86_64 platform, the value I use is:
Reasons are:
0xDEADBEEFis already very well known for this purpose in 32bit,0xDEADBEEFDEADBEEFin 64bit is just more 'backward compatible'