RFC: Automatic variable initialization
lists.llvm.org
lists.llvm.org
However, nil has a distinct type. Thus:
(let (x) ;; not initialized
;; ...
(when condition
(setf x ...))
(numeric-code x)) ;; still blows up if condition was false
nil is the empty list. The risk of a bug where a local variable holds an empty list that should have been initialized to some non-empty list seems low.
nil is also Boolean false. The risk of a bug where a local Boolean variable was implicitly initialized to false, but should have been true, also seems low.
This is why I intentionally leave variables uninitialized rather than put bogus initialization values. Example:
int x;
if (cond) {
x = foo();
} else {
x = bar();
}
This would be a flag to enable on release builds; a bug mitigation technique rather than a debugging technique.
Something like Java's final would be useful in such a scenario.
I write code which looks exactly like this, except I only do this for final variables - the compiler throws an error if I add a branch which doesn't explicitly set it.
That's pretty useful.
https://docs.oracle.com/javase/specs/jls/se10/html/jls-16.ht...
Java was my first language, so i took it for granted; i was alarmed when i found out that C and C++ don't have it. It's saved my bacon too many times to count.
FWIW, Rust does have this rule; this code:
fn show(x: usize) {
let message;
if x % 2 == 0 {
message = "even";
}
println!("{} is {}", x, message);
}
int val;
if (do_something(&val)) { ... }
I think in general a defined default value is a good thing. Maybe it shouldn't be 0 but something like INT_MIN so you clearly see what something is wrong.
INT_MIN (0xffff) has a sort of collision with PCI MMIO read failures (timeouts, unsupported request, etc), which return all-bits-1.
They tend to be low-probability values so if you get two of them together it's almost always a bug. They don't tend to collide with other things and are far enough away from overflow that they don't accidentally get masked by an off-by-one bug. They have interleaved 0's and 1's so that if you get a bit error, it sticks out. They're also obviously different enough that if they get copied, they kind of stick out.
I tend to "initialize" my data to these by default. They also tend to be my go to for "deinitializing" data.
It's remarkable how often I catch bugs in my C code simply by scanning RAM for those values.
If you have faith your compiler will warn/error on use of uninitialized variables (and GCC/Clang seem to warn about it pretty reliably these days, but C is an old language and compilers certainly have not always warned about it), go ahead and continue that practice. In my experience, when comparing accidental zero initialization to accidental undefined behavior, I think usually the accidental zero is easier to understand and correct when your tools are (maybe!) GDB. If you have valgrind, that's a different story.
But they can run large parts of the code in tests and those test can be run under valgrind.
By the way, Valgrind has an API, using which variables that have been reliably cleared to zero can be marked as de facto uninitialized.
However, in this situation, it requires integration of use of the Valgrind API into the compiler, which has to generate code on function entry points to not only clear the locals, but do the Valgrind API call to mark the memory.
But then this will of course yield false positives from Valgrind when programs rely semantically on the initialization for correctness and not just to have predictable behavior for a forgotten initialization.
Not the latest version, though; support is still only offered for macOS Sierra.
My point is that this is a useful tool when I can't use Valgrind, or any other sanitizer, due to performance reasons or because they don't exhibit the undefined behavior I was trying to track down. And I wouldn't initialize to zero: I'd use pattern initialization to 0xfa or whatever is the standard " lowest probability byte that represents uninitialized memory but is still likely to fault or produce blatantly wrong results".
Here is my main argument: once tool is used and discovers the uninitialized variable, of course, there will be a fix applied: either to initialize the variable, or to assign a value to it later in a conditionally executed path in order to prevent the uninitialized use in that path. Either way, when this fix is applied, the tool will thereupon stop detecting an uninitialized value in the scenario that is being tested. And the fix can be applied with a bogus value. In other words, our goal is to prevent the use of an uninitialized variable, and the only way to do that is to put a value in it before it is used, and that always carries the risk of a wrong value being put there.
Additional argument: we know that some initial value is wrong only because we have some test which reproduces the situation of that value being set up and used, and that test fails. If we don't have such a failing test, it doesn't help us to leave the variable uninitialized, if our goal is to establish a correct value for that situation for which that test is missing. The Valgrind tool will certainly inform us that the variable is uninitialized, but in reference to a different test. Our debugging effort will establish a correct value for that test, without any guarantee that the value is correct fro the untested situation.
Correctness is not achieved until all execution paths access a stable value of the variable. We can't magically make the jump from "uninitialized" to "correct initial value" with zero risk of "bogus value". The tool which detects uses of uninitialized data is silenced once we supply a value for that data; it doesn't help with the issue of choosing the correct value.
So basically the "don't initialize" argument is implicitly based on the belief that there is no way to detect a bogus initial value, except for the end user of the software to discover a malfunction in the field. And that, magically, even though we can't reproduce the consequences of a bad initial value in development, it helps us to instead leave the variable uninitialized and run everything under Valgrind; we will then be alerted to the uninitialized variable, and not make a mistake in choosing a value for it, even though we still don't have a test case which distinguishes bogus from non-bogus value.
In summary, it is not a credible proposition that the initial coding (with no test case) carries a risk of choosing a wrong initial value, whereas post-mortem fixing of an uninitialized variable bug (still with no test case) does not carry a risk of choosing a bogus initial value.
What makes non-trivial uninitialized object memory higher penalty or lower risk?