| |||||||||||||
What Every C Programmer Should Know About Undefined Behavior #3/3What Every C Programmer Should Know About Undefined Behavior #3/3Posted May 23, 2011 10:32 UTC (Mon) by cesarb (subscriber, #6266)In reply to: What Every C Programmer Should Know About Undefined Behavior #3/3 by iabervon Parent article: What Every C Programmer Should Know About Undefined Behavior #3/3
> [...] developers assume that uninitialized variables contain unspecified values of their types (rather than accessing them causing undefined behavior). If a compiler were to use a special "undef" value [...]
There is at least one processor architecture where accessing uninitialized variables can crash your program. It is not the compiler in this case, it is the processor itself which has a special "undefined" value.
See this article: "Uninitialized garbage on ia64 can be deadly" on Raymond Chen's blog (http://blogs.msdn.com/b/oldnewthing/archive/2004/01/19/60...).
(Log in to post comments)
What Every C Programmer Should Know About Undefined Behavior #3/3 Posted May 23, 2011 19:45 UTC (Mon) by kripkenstein (subscriber, #43281) [Link]
> There is at least one processor architecture [ia64] where accessing uninitialized variables can crash your program. It is not the compiler in this case, it is the processor itself which has a special "undefined" value.
Somewhat similar: If you consider JavaScript an 'architecture', then when compiling C or C++ to JS (using Emscripten), reading uninitialized values gives you a JS 'undefined' value, which isn't a number (since you are doing something like x = [1,2,3]; y = x[100]. So y will be undefined).
This doesn't crash, but it can lead to very unpredictable behavior. For example, reading such a value into x, then x+0 != x (since undefined+0 = NaN, and NaN != undefined).
What Every C Programmer Should Know About Undefined Behavior #3/3 Posted May 25, 2011 14:29 UTC (Wed) by welinder (guest, #4699) [Link]
The old alpha architecture can do that too, at least for floating-
point data.
|
|||||||||||||