0

Consider:

int a[100];

Is it possible for the uninitialized value in a[i] (where 0 < i < 100) to be negative?

Bob__
  • 12,361
  • 3
  • 28
  • 42
Saurabh Shubham
  • 43
  • 2
  • 14

3 Answers3

2

Yes, why wouldn't it ? Theses bits can be anything and the sign of an integer is usually its MSB (most significant bit). If that bit is 1, then the int will be considered negative.

I see little point of knowing that though. You can't rely on garbage data as it's undefined behavior.

AlexG
  • 1,091
  • 7
  • 15
  • Thanks for the clarification. I was thinking of using the garbage value in my program. – Saurabh Shubham Apr 07 '17 at 11:28
  • Undefined behavior as per what part of the standard? Reading a trap represenation is undefined behavior. What makes you think this applies here? – Lundin Apr 07 '17 at 11:37
1

The answer is that it can be any value.

However don't consider using it for anything. This program :-

void func()
{
    int a[100];
    if (a[10] == 0 || a[10] != 0) {
        std::cout << "The value is either zero or not zero\n";
    }
}

It is entirely possible that your compiler won't print the message because accessing an initialized value is undefined behavior and the compiler can do anything including stuff like this. And increasingly compiler do.

jcoder
  • 29,554
  • 19
  • 87
  • 130
0

I think if you understood the meaning of garbage value, you wouldn't ask this question.

When you declare a variable, a piece of memory is allocated to it. This memory could be anything that the operating system considered free, and hence could contain bits that were written by some previous program to which this same memory was allocated.

The previous program could have been anything (a music player, a game you were playing, an image that you viewed, etc.). Thus that data is just a bunch of bits, now to be used as integer in your code. So your compiler will read it as an integer, which is the reason why it could be negative if the first bit is 1 as mentioned by AlexG

anirudh
  • 4,116
  • 2
  • 20
  • 35
  • Thanks for the clarification. I was thinking of using the garbage value in my program. – Saurabh Shubham Apr 07 '17 at 11:30
  • 1
    It's more complicated than that. Reading from uninitialised variables invokes undefined behaviour. Not only should you not expect any particular value, you should not expect your program to continue to work at all. – davmac Apr 07 '17 at 11:30
  • That is what I said, the bits read are from some other previous program, so could contain anything, thus totally unreliable... – anirudh Apr 07 '17 at 11:33
  • 1
    @davmac do you know of any actual platforms where reading an uninitialized value will cause the program to crash? – Jeremy Friesner Apr 07 '17 at 11:35
  • @JeremyFriesner I believe they do exist. However, even on a "regular" platform, doing so could break certain compiler assumptions leading to strange behavior outside of what you might expect, including leading to a crash. – davmac Apr 07 '17 at 11:37
  • @anirudh you said "your compiler will read it as an integer", what I said is that the behaviour is _undefined_. These are different things. – davmac Apr 07 '17 at 11:38
  • @davmac Reading a variable with indeterminate value only invokes undefined behavior in case the system is a wildly exotic one with trap represenations. That this is alway UB is mostly a myth, the standard is much more nuanced. – Lundin Apr 07 '17 at 11:40
  • @Lundin, the link from your own answer says otherwise, at least for variables of automatic storage whose address is not taken. Arguably, though, you're right that this doesn't apply in this case, since accessing an array element requires decay to a pointer which presumably qualifies as taking the address. – davmac Apr 07 '17 at 11:48
  • @davmac Yes that's a special case but we don't know if it applies here. Though it is terribly hard to use arrays without taking their address, as it turns out... – Lundin Apr 07 '17 at 11:56
  • @Lundin, yes, as I said. However your implication that reading from _any_ unitialised variable is only UB if the implementation has trap representations is clearly incorrect. – davmac Apr 07 '17 at 11:58
  • (As follow up, the rules for C++ seem to be different and in fact do describe using an uninitialized value as undefined behaviour regardless of the possibility of trap representation; N3690 4.1 _Lvale-to-rvalue conversion; therefore, for this C++ question, it is correct to say that UB is invoked). – davmac Apr 07 '17 at 12:35