Hello guys,
So, I'm wondering if there's a good marker to choose in C, apart from the common 0xDEADBEEFor the less appealing (for proper code) 0x0BADA550.
What's your favorite? Is there any reason to choose one particular value or another?
views:
148answers:
6
A:
0xBABECAFE, 0xBADADD00, 0xBADBAD00, 0xFADEFADE
0xCAFEBABE is, I understand, the magic number for Java. The only thing that makes one better than another is how unlikely it is to appear in data or uninitialized memory. So don't use 0x00000000 or all Fs.
Nathon
2010-09-09 17:29:57
A:
It depends what you're trying to mark. For example, do you need to distinguish between allocated but uninitialized memory and deallocated memory? If so, you need different markers for the two.
Jonathan Leffler
2010-09-09 17:30:24
+4
A:
The only marker that I can think of that might have more than asthetic value is 0xCCCCCCCC. If, through some kind of error, it was executed 0xCC translates to an INT 3 instruction.
This will work in IA-32 and x86-64. Im not sure if there are equivalents for other architectures.
torak
2010-09-09 17:38:50
... on x86(?) machines...
dmckee
2010-09-09 17:58:50
@dmckee: Ahh yes. I'll add that in. Thanks!
torak
2010-09-09 18:26:12
I think 0xCCCCCCCC has an additional advantage in that it typically points to kernel virtual memory space, attempting to use such a pointer from userspace would crash the application (which is great for debugging).
Matt Joiner
2010-09-10 00:34:51
+6
A:
Wikipedia has a whole page on this subject; it provides a lot of examples and famous software in which they are used.
Anyway, if you are working on x86 you should consider following @torak's suggestion, memory filled with int 3 saved me several times. If you feel creative, you may make it more recognizable and use CC90CC90, which translates to alternated int 3 and nop.
Matteo Italia
2010-09-09 17:41:14
+3
A:
Well I always picked 0x80000000, 0x80000001 incrementing for each new region type to tickle unexpected values with signed integers. Use of these values will be strangely large for unsigned types, largely negative for signed types, and abruptly become positive for any subtractions made (thereby testing for other bugs at the same time). This has another neat side effect, in that various ALU bits will be set such as overflow, which can be detected through use of -ftrapv and other compiler flags.
Matt Joiner
2010-09-09 17:41:53
A:
Everyone has their preference. If everyone on the team uses a different marker, it can help to determine the source of an error. As in:
"DEADBEEF? Oh, this must be from John's code."
ablerman
2010-09-09 17:46:45