-3

I am fairly new to C++. I was going through tutorialspoint course on the same. While using its inbuilt compiler (GNU GCC v7.1.1) to learn about pointers, I found a rather unusual behaviour (stated in observation section below) that I just cannot comprehend.

I performed following scenarios trying to reach some concrete inference-

Scenario 1

Code -

int main () {
   int  *ptr;
   cout << "The value of ptr is " << ptr;
   return 0;
}   

Output -

The value of ptr is 0

Scenario 2

Code -

int main () {
   int a =20;
   int  *ptr;
   cout << "The value of ptr is " << ptr;
   return 0;
}   

Output -

The value of ptr is 0x7ffff0278150

Scenario 3

Code -

int main () {
   int a =20;
   int  *ptr;
   cout<<"The address of a is "<<&a<<"\n";
   cout << "The value of ptr is " << ptr;
   return 0;
}

Output -

The address of a is 0x7ffcee0e2e74

The value of ptr is 0

Observation

Scenario 1: By default, either pointer is pointing to NULL or OS has cleaned out existing data from the memory location assigned to ptr. Anyhow, I don't find this output unexplainable.

Scenario 2: This is weird scenario. Just assigning value to some new variable causes my pointer to store some garbage memory address. Just to note, I haven't explicitly assigned my pointer to point to that variable or any other variable for that matter.

Scenario 3: Independently, this scenario is simplest to understand. But when taken into consideration along with 2nd, it complexes 2nd even more.

Can anyone please explain or hypothesise on what could possibly be happening around here ??

user2653926
  • 610
  • 7
  • 23
  • 7
    Undefined behaviour is undefined. – Jonathan Potter Mar 25 '18 at 08:57
  • 3
    It's simple: Uninitialized local (and non-static) variables really are uninitialized. They will have an *indeterminate* value. Using them except to assigning to them leads to [*undefined behavior*](https://en.wikipedia.org/wiki/Undefined_behavior). And that's the whole story really. Attempting to argue about UB is pointless. – Some programmer dude Mar 25 '18 at 08:57
  • please go through the observation section :) – user2653926 Mar 25 '18 at 08:58
  • 2
    To summarize you cannot do what you are doing. Your code is ill-formed and can do anything from appearing to work correctly, giving some recognizable or unrecognizable output or SegFault'ing -- take your pick. If your variable ain't initialized -- you ain't allowed to try and look at it... Yes, a pointer is just a variable that holds the address for something else as its value. – David C. Rankin Mar 25 '18 at 09:00
  • 1
    Possible duplicate of [(Why) is using an uninitialized variable undefined behavior?](https://stackoverflow.com/questions/11962457/why-is-using-an-uninitialized-variable-undefined-behavior) – Mateen Ulhaq Mar 25 '18 at 09:01
  • There's even a small chance that your code could elect an orange floor mop to be the next President of the United States...! – Mateen Ulhaq Mar 25 '18 at 09:02
  • 1
    Too late, that already happened -- but I thought we got a bleach-blond cheeto. – David C. Rankin Mar 25 '18 at 09:03

2 Answers2

2

All your observations are invalid. You cannot read from an int* which is not initialised and which has not been assigned a valid value. If you do so, which you do in all scenarios by trying to print the pointer value, then the behaviour of your program (and not only the output) is undefined by the C++ language specification.

Christian Hackl
  • 27,051
  • 3
  • 32
  • 62
1

You "cannot understand behavior of unassigned pointer" because it's behavior is not defined by C++.

That's why you should always set a new pointer to NULL or nullptr if you do not want to initialize it upon declaration.

TalvinEx
  • 13
  • 5
  • Initialising the pointer to `nullptr` (`NULL` is obsolete since C++11) is often not enough, though, and you might just trade one kind of undefined behaviour (reading an uninitialised pointer value) for another (dereferencing `nullptr`). – Christian Hackl Mar 26 '18 at 07:22
  • @ChristianHackl That's interesting, I thought that would generate a compiler error, turns out it doesn't. So `nullptr` is only used to prevent accidentally accessing memory, that might already be in use by another program or the operating system? If initialising a pointer to `nullptr` is not enough, is there a "save" way to declare a pointer without assigning a value? – TalvinEx Mar 26 '18 at 21:15
  • `nullptr` is not used to "prevent" anything. It's a valid pointer value meaning "the pointer does not point to an object", which is not the same as "it's undefined what the pointer means". So unlike with uninitialised pointers, you can safely compare `nullptr` to other pointers, and you can safely print its value. You just cannot dereference it (because that's undefined behaviour). As for your last question, no, real safety cannot be achieved with any technical tricks on such a low level; safety with pointers is achieved by program logic on a higher level. – Christian Hackl Mar 27 '18 at 05:15