Uninitialized variable wtf
-
While making an application I forgot to initialize an integer. Printing it out it gave me:
Number of different ISO_639_language_codes found in RMF(freq: baadf00d)
it enlightened my day :D
-
Uninitialized memory on IBM RS6000s used to be set to 0xdeadbeef.
Still true???
-
@Rick said:
Uninitialized memory on IBM RS6000s used to be set to 0xdeadbeef. Still true???
Don't know about that, but we use it. You'll occasionally hear things around here like, "Whoops, got a deadbeef error..."
Mind you, my favorite along those lines is 0xDECAFBAD.
-
ircu sets pointers to 0xDEADBEEF when we free memory the memory they were pointing at.
-
Funny values for uninitialized pointers make it obvious they were uninitailized when errors happen, but then, don't NULL's do that too? You can actually check for NULL's, and 0xDEADBEEF may actually be a valid address in some situations.
-
@Corona688 said:
Funny values for uninitialized pointers make it obvious they were uninitailized when errors happen, but then, don't NULL's do that too? You can actually check for NULL's, and 0xDEADBEEF may actually be a valid address in some situations.
True, but if you're not committed to nulling the memory in release mode, it's hard to distinguish properly initialized values from erroneously uninitialized ones. This might be a problem if you use something like STL::vector, setting capacity and then using another mechanism to initialize or recycle values.
-
@Corona688 said:
Funny values for uninitialized pointers make it obvious they were uninitailized when errors happen, but then, don't NULL's do that too? You can actually check for NULL's, and 0xDEADBEEF may actually be a valid address in some situations.
One argument I've heard for non-NULL values is that using an odd address will often cause a processor exception as soon as it's dereferenced, allowing you to see the error closer to where it was actually caused in many cases. It's probably less of an issues these days where we have protected memory and the entire first kilobyte of memory can be set to unreadable and unwritable, but that wasn't always the case. Old habits die hard.
-
I've always been a fan of 0xD06FECE5 myself.
-
@dcardani said:
One argument I've heard for non-NULL values is that using an odd address will
often cause a processor exception as soon as it's dereferencedIIRC, not on x86.
-
@dcardani said:
@Corona688 said:
Funny values for uninitialized pointers make it obvious they were uninitailized when errors happen, but then, don't NULL's do that too? You can actually check for NULL's, and 0xDEADBEEF may actually be a valid address in some situations.
One argument I've heard for non-NULL values is that using an odd address will often cause a processor exception as soon as it's dereferenced, allowing you to see the error closer to where it was actually caused in many cases.
x86 allows non-aligned access to any memory address. On the other hand, in protected mode, write access to memory address 0 by a user-mode program is always an exception, and read access may be an exception.
