0xDEADBEEF equivalent for 64-bit development?

前端 未结 12 576
栀梦
栀梦 2021-02-02 06:46

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 immedi

相关标签:
12条回答
  • 2021-02-02 06:55

    According to Wikipedia, BADC0FFEE0DDF00D is used on IBM RS/6000 64-bit systems to indicate uninitialized CPU registers.

    0 讨论(0)
  • 2021-02-02 06:55

    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).

    0 讨论(0)
  • 2021-02-02 06:56

    0xDEADBEEFBAADF00D might work.

    0 讨论(0)
  • 2021-02-02 06:58

    As the system I worked on basically runs on x86_64 platform, the value I use is:

    0xDEADBEEFDEADBEEF
    

    Reasons are:

    • On x86_64 platform, only the low-order 48 bits are used for virtual memory address in current implementation, meaning any value > 2^48 should work: https://en.wikipedia.org/wiki/X86-64
    • As 0xDEADBEEF is already very well known for this purpose in 32bit, 0xDEADBEEFDEADBEEF in 64bit is just more 'backward compatible'
    0 讨论(0)
  • 2021-02-02 06:59

    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.

    0 讨论(0)
  • 2021-02-02 06:59

    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.

    0 讨论(0)
提交回复
热议问题