0

I'm trying to figure out why assigning a pointer to an uninitialized variable then printing both the pointer and its value leads to a segmentation fault. From what I know of C++, printing p should just give out the address of x, while printing *p should just give out whatever garbage value was randomly assigned to x. 

int x;
int* p = &x;
cout << p << *p << endl;
Noa Kim
  • 9
  • 1
  • 1
    The behavior is undefined if you attempt to access an uninitialized variable. – PaulMcKenzie Sep 03 '19 at 00:44
  • [works for me](https://repl.it/repls/SteepUprightAutomaticparallelization) – gman Sep 03 '19 at 00:49
  • 1
    @gman "works for me" doesn't really apply here. UB may always "work for you" but it's still UB. – François Andrieux Sep 03 '19 at 00:53
  • 1
    *"whatever garbage value was randomly assigned to x"* An uninitialized variable is not just a variable containing garbage. It's value is indeterminate which is a special characteristic. It's UB to try to read it's value. Usually, you get garbage but anything can happen. Lucky for you, you've just observed a different behavior. Maybe the compiler deduced that `*p` must never be reached and did some optimizations that break your code or something else happened. But the bottom line is `*p` is illegal here and anything can happen including a segfault. – François Andrieux Sep 03 '19 at 00:54
  • This is just one of the things that [demons that fly out of your nose](http://www.catb.org/jargon/html/N/nasal-demons.html) like to do, once they're set loose. – Sam Varshavchik Sep 03 '19 at 00:56
  • *I'm trying to figure out why assigning a pointer to an uninitialized variable then printing both the pointer and its value...* -- And guess what -- the compiler is free to say "what the heck are you doing?" and then generate crap. One of the manifestations of undefined behavior. – PaulMcKenzie Sep 03 '19 at 00:57
  • 2
    I'd be interested to know how you compiled this so it crashes. It would be an ideal example to illustrate the consequences of UB. – François Andrieux Sep 03 '19 at 00:57
  • 2
    This is surprising, even for undefined behavior, because there’s no obvious optimization benefit from doing anything other than the naïve thing. But it still needs a reproducer to analyze further. – Davis Herring Sep 03 '19 at 01:00
  • @DavisHerring Too late for coffee. I don't know what I was thinking... – David C. Rankin Sep 03 '19 at 05:10
  • Yes, the behavior is undefined, but I'm surprised you got a seg fault. Are you sure the code in your question is exactly the code you compiled and ran? I note that it's not a complete program; can you show us a [mre]? (I tried very recent versions of g++ and clang++ with `-O0` through `-O3`, and always got a plausible pointer value and an arbitrary integer value, never a seg fault.) – Keith Thompson Sep 03 '19 at 08:27
  • Incidentally, you'll want to leave a space or newline between `p` and `*p`. – Keith Thompson Sep 03 '19 at 08:28

1 Answers1

1

while printing *p should just give out whatever garbage value was randomly assigned to x.

Not sure where you got this impression, but it is based on false assumption or wrong expectation. Standard specifies and creators of the compiler follows that reading value of unintialized variable either directly by using variable name or indirectly, using pointer or reverence leads to Undefined Behaviour. So segmentation fault probably the best outcome you get in this case as it lets you to fix error in your code much easier that getting some random value. But beware you cannot expect of segmentation fault happening either, when you get on UB territory you cannot expect anything particular. It is your job as a developer not doing that.

Slava
  • 43,454
  • 1
  • 47
  • 90