0

For instance, consider the following:

int main(void) {
    int K;
    int Y;
    printf("%d", K==Y);
    return 0;
}

Is it possible for the output to ever be a 1?

R. Kap
  • 599
  • 1
  • 10
  • 33

3 Answers3

3

The result of reading the value of an uninitialized variable is undefined, meaning that anything could happen. I would say it's possible for the output to be a 1.

Pinyi Wang
  • 823
  • 5
  • 14
  • shame - it was answered in the comments. Plagiarism. It is the many times duplicate as well. – 0___________ Aug 08 '17 at 20:13
  • 2
    Comments are not answers. This is an old issue [... comment has been reposted as an answer by another user?](https://meta.stackoverflow.com/q/288847/2410359) – chux - Reinstate Monica Aug 08 '17 at 21:32
  • 1
    @PeterJ site policy is that answers should not be posted in comments. I would upvote anyone who reposted a comment as an answer (if the answer is correct, of course) . If the commentor wants credit for an answer they should have posted an answer in the first place – M.M Aug 08 '17 at 22:50
  • Maybe I am getting old, but as I see the honour is not something which has any value today. – 0___________ Aug 08 '17 at 22:58
3

The thing here is that both variables K and Y have automatic storage duration, and its address is never taken - it could have been declared with register storage class, C11 6.3.2.1p2 says that

If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined.


Because the behaviour is undefined anything might happen. In practice this rule exists because there are computer architectures where the processor registers would be set to "unset" upon an entry to a function - accessing such a register would actually trigger a hardware trap that will cause the program to crash.

This rule has then lead to other compilers doing all sorts of wild stuff with these - it might be that no register will be allocated for a variable before it is assigned to, so you might see the value of the variable changing over executions, so it might be that consecutive invocations

printf("%d", K==Y);
printf("%d", K==Y);

might print different values.

2

Reading uninitialized local variables with automatic storage has undefined behavior. Anything can happen:

  • the output can be 1
  • the output can be 0
  • the output can be Hello world
  • there might not be any output
  • the computer might go back in time 9 months or so, which would be a handy way to try and correct some historical accidents, or at least monetise them. Alas unlikely to happen.
chqrlie
  • 131,814
  • 10
  • 121
  • 189
  • Note; I think reading uninitialized local `unsigned char` has _unspecified behavior_, not _undefined behavior_. The value is not specified, yet it will not cause a crash, exception, etc. – chux - Reinstate Monica Aug 08 '17 at 21:23
  • @chux according to DR 260, it produces an indeterminate value; operations on indeterminate values produce indeterminate values; and passing indeterminate values to library functions causes undefined behaviour. (All of this holds even if there are no trap representations). So `K==Y` is also indeterminate, and trying to printf it causes UB. – M.M Aug 08 '17 at 22:52
  • @M.M [DR 260](http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm) does not discuss the indeterminate-ness of `unsigned char`, but a pointer to that type after the pointer was free'd. An uninitialized `unsigned char ` is not of _indeterminate value_, but _unspecified value_ as it is specified to not have a trap representation. – chux - Reinstate Monica Aug 08 '17 at 23:44
  • @chux There are no special cases for certain types in DR260. An uninitialized unsigned char has an indeterminate value, just the same as any other type. Even if there are no trap representations for the type, having indeterminate value differs from being initially unspecified; e.g. passing indeterminate value to library function is still UB even if the indeterminate value couldn't be a trap representation. This stuff is all fleshed out in actual answers (e.g. [mine here](https://stackoverflow.com/a/25074258/1505939)) – M.M Aug 09 '17 at 00:02
  • 1
    @M.M Good answer, yet I found it before and still now it uses selective cases for the point - _most_ of which I agree. Perhaps, at a latter time, rather than here, I will detail my thoughts for your consideration. Thanks for your professional vigor. – chux - Reinstate Monica Aug 09 '17 at 02:28