Dave Korn wrote:
You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
and for a way to ensure correctness, I tried this
(switch register/volatile in the declaration lines in comp
and r to see the effects).
I didn't get that far. Before the first call to comp the program has
already accessed uninitialised memory:
[...]
for (size_t c=0; c < hi + 2; ++c) {
if (a[c]) {
Uninitialised variable access. Boom. *NOT* correct.
Right, but not so much Boom because `a` is full of don't care
shorts. Rather because if x, y, and z are register variables
they might never be assigned; if a[c] happens to always yield 0,
then the function r adds uninitialised local variables in
return x + y + z;
GCC tells us, anyway.
And then there is + 2 in the loop condition which
might move c off the end of a before a[c]. Another bug,
unrelated to uninitiliased variables.
If you remove the if (a[c]) entirely here and also the + 2
(left over when quickly scribbling a program),
then x, y, and z will be computed. I think the assert
statement has a lot more to say about correctness
than when the register variables get some (which?) initial
values that are not used ever.
In what sense of the word 'correct' do you claim this example is correct?
The example was intended to demonstrate two things:
1) initialising variables doesn't necessarily make programs any
more correct.
Initialisation might be redundant, distracting, and inviting
asymmetric expressions, see below. A good initial value
for some algorithm might depend on other values, hence it is
known only after a conditional. Pseudo code:
f(a, b):
x <- some initial value
# expr doesn't show init really depends on cond(a, b)
...
if cond(a, b):
x <- a different initial value # asymmetry here
compute(x, ...)
else:
compute(x, ...)
2) if putting local variables in registers becomes impossible
there will be a significant cost. I wanted to get an impression
of the cost. That's the reason for writing volatile in the
declaration lines. Just for demo.)
-- Georg
