Hacker News Reader

Comment by CJefferson | Hacker News Reader

I wish one of clang, or gcc, would gain an option to let me initalise any stack variable to 0 if there is not an explicit assignment to it. I suspect (and I'd really like to know) that with optimisation, the practical cost of this would be 0, and a whole bunch of issues would be cleaned up.

For malloc, I can already choose fairly easily to 0 out memory, but here it can get more expensive if one isn't careful.

View on HN

msvc detects uninitialized stack variable usage as a run time check and throws an exception.

I've always wondered why the compiler can't warn about this at compile time. It should know when uninitialized stack space is being used since it is, after all, the compiler artificially designating what the stack is!

Compilers are certainly capable of warning about uses of uninitialized variables, but there are necessarily false positives and false negatives as the problem is in general undecidable.

Is it? Why isn't it as simple as a rule stating that a warning is generated whenever, in the AST, a variable is used on the RHS before it's ever used on the LHS of an expression?

(Probably something to do with globals/scope, right?)

When you have ifs and for loops around, it maybe depend on arguments to the function, and also the return values of functions you call.

You could say "warn if there are any inputs, and any return values for any function I call, that can lead to a problem" but I suspect that would produce too many false positives.

That's easy enough to do (and plenty of compilers do it), the problem is determining it for things set conditionally (uncomputable in the the general case) e.g.:

  int y, z;
  if (x < 3) { y = 0; }
  if (x < 4) { z = y + 1; }

Well, in the most general case where x's value can only be determined at runtime, most any compiler can and will assume that the initial if could or could not be hit and will therefore assume that y could, conservatively, be uninitialized. Its not uncomputable, its just conservative.

I mean it's undecidable even if x is computed from purely static values: `x` can be the result of an arbitrary C-function and C is Turing complete.

If x is a 32-bit int, then there are only ~4bil possible values to consider. If any of them not ruled out already would lead to an uninitialized read, issue a warning.

But this is still an error when x == 3, y will be uninitialized when z is set.

There are plenty of warnings in -Wall that are conservative. For example in g++ C++, out of order constructor initialization even for primitive types is warned for the same reason.

In this case the use of y on the RHS without explicit initialization should be warned.

It sounds annoying, but having a bug's behaviour change between different build modes is much more irritating.

I probably should have made the second conditional `(x < 2)` rather than `(x < 4)` so that the compiler should not generate a warning. Here a serious compiler would likely be able to statically determine that the variable was always initialized, but for a sufficiently complex function call (even an inlined one) it would not.

The compiler could just be "conservative" like you said and warn whenever it couldn't statically determine validity, but note that initializing e.g. `y = 0` has a performance cost (cf. reordering constructor initializers).

I think 90% of developers would rather the compiler just complain there (for any condition in the if). Considering that without the compiler warning/error we have one of the most common sources of hard-to-find bugs, and with the compiler complaining the developer just has to type ` = 0`, it seems like an easy choice to me.

In general it's impossible. Consider this C program:

    void do_something(int *);

    int f() {
        int x;
        do_something(&x);
        return x;
    }

Is the return of x a use of initialized memory? Maybe. Relink the program and the answer might change.

Isn't x already initialized to zero as it's static?

I googled it and this[0] seemed relevant:

1655 — if it has arithmetic type, it is initialized to (positive or unsigned) zero;

[0] http://c0x.coding-guidelines.com/6.7.8.html

> Isn't x already initialized to zero as it's static?

If x was static, this would be true. But in this case, x is just a default automatic variable. For x to be static, it would have to be declared outside the function, or have the keyword 'static'.

OK, thanks, appreciate the correction. I see what I had wrong now.

For anyone else interested in a longer explanation these SO comments are pretty informative: http://stackoverflow.com/questions/14049777/why-are-global-v...

What you want is just a few lines up:

    1652 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.

(x is an 'auto' variable in the given program.)

Yeah, that's what I get for replying without making sure I'm correct! :-)

You are correct that it is undecidable if do_something is from another object file (even then there can be some linker magic).

But the vastly more common case is uninitialized usage in the same compilation unit and I argue that that case should give a warning.

Even when proving an uninitialized read is undecidable, it is still possible to note that a particular bit of code contains a path which could lead to an uninitialized read, or that it is is impossible to prove that an uninitialized read doesn't happen, in which case a warning is still likely to be appropriate.

Reply on news.ycombinator.com