Hacker News Reader

Comment by gingerBill | Hacker News Reader

> You're making it sound like uninitialized variables _have_ a value but you can't be sure which one.

Because that's a valid conceptualization you could have for a specific language. Your approach and the other person's approach are both valid but different, and as I said in another comment, they come with different compromises.

If you are thinking like some C programmers, then `int x;` can either have a value which is just not known at compile time, or you can think of it having a specialized value of "undefined". The compiler could work with either definition, it just happens that most compilers nowadays do for C and Rust at least use the definition you speak of, for better or for worse.

View on HN

> C programmers, then `int x;` can either have a value which is just not known at compile time

I am pretty sure that in C, when a program reads uninitialized variable, it is an "undefined behavior", and it is pretty much allowed to be expected to crash — for example, if the variable turned out to be on an unallocated page of stack memory.

So literally the variable does not have a value at all, as that part of address space is not mapped to physical memory.

It is "undefined behaviour" in C (which is an overloaded term which I will not discuss why I hate it in this comment). But my point was that is how many people conceptualize it, and for many things people do expect it to be one of the possible values, just not knowable ahead of time.

However, I was using that "C programmers" bit to explain the conceptualization aspect, and how it also applies to other languages. Not every language, even systems languages, have the same concepts as C, especially the same construction as "UB".

As someone who recently wondered what kinds of things might happen, im actually very glad for GPs clarification.

It is undefined in C for automatic variables whose address was not taken (and in this case a compiler should be able to warn).

Interestingly enough, C++26 introduces "erroneous behavior" and uses it for uninitialized variables, rather than undefined behavior.

The problem is that “allowed to be expected to crash” is one interpretation. Another is “0 initialized” (which debug runtimes sometimes use), another is “whatever was on the stack last time” and another is “we can reorder program and eliminate what you think is logical code”.

    int main() {
      int val;
      if (val == 3) {
        cout << “here” << end;
      }
      return 0;
    }

A perfectly legal interpretation of this program is to remove the call to cout, as is just printing “here” on every run.

> So literally the variable does not have a value at all, as that part of address space is not mapped to physical memory.

There are vanishingly few platforms where the stack you have in a C program maps to physical memory (even if you consider pages from the OS)

Reply on news.ycombinator.com