-3

I'm playing around with some code to understand how pointers work. I made a non-pointer variable a double and it caused a segmentation fault. I have no idea why this is happening since the variable is not interacting with anything else in the program.

#include <iostream>

int main() {

    int firstValue;
    double secondValue = 54.6;

    int *p1;
    *p1 = firstValue;
    p1 = &firstValue;
    *p1 = 10;
    std::cout << "&firstvalue is " << &firstValue << '\n';

    std::cout << "firstvalue is " << firstValue << '\n';

    std::cout << "p1 is " << p1 << '\n';

    std::cout << "*p1 is " << *p1 << '\n';
}

exited, segmentation fault;

HolyBlackCat
  • 78,603
  • 9
  • 131
  • 207
Anakita Smiles
  • 3
  • 2
  • 3
    `*p1 = firstValue;` is causing segmentation fault – KamilCuk Sep 11 '19 at 22:09
  • 4
    For `*p1 = firstValue;` to work, `p1` has to point to some existing `int`. – HolyBlackCat Sep 11 '19 at 22:09
  • 2
    Adding that `double` may have exposed the error with a seg fault, but it didn't cause it. This is a good lesson in undefined behaviour. Since the behaviour of `*p1 = firstValue;` is undefined (writing to invalid pointer), the program can do just about anything, and that includes looking like it works correctly. But often it only takes a small perturbation, adding an unused variable in this case, to make the program visibly fail. – user4581301 Sep 11 '19 at 22:15
  • `*p1 = firstValue;` segfaults because `p1` is not pointing at any allocated memory. – Remy Lebeau Sep 11 '19 at 22:20
  • 3
    Turn on compiler warnings. https://gcc.godbolt.org/z/Q06Mf3 – Raymond Chen Sep 11 '19 at 22:30
  • [Why should I always enable compiler warnings?](https://stackoverflow.com/q/57842756/995714) – phuclv Sep 12 '19 at 00:23

1 Answers1

0

I have no idea why this is happening since the variable is not interacting with anything else in the program.

This is a sign of undefined behavior. The variable is not directly interacting with anything else, but it is present in the program. That can be enough to change how the compiler deals with undefined behavior, potentially changing a silent no-op into a crash.

[In your case, there is undefined behavior when you use the value of a variable before assigning a value to that variable. Specifically, int *p1; declares a variable without assigning a value to it, and the "*p1" in the next line uses the value of p1 (to get the address to where the value of firstValue is copied). Similarly, no value has been assigned to firstValue at that point, so you get another bit of undefined behavior in the same assignment. Realistically, though, it's the uninitialized pointer that causes the segmentation fault.]

Relying on something like declaring a new variable to reveal undefined behavior is not a great plan. A better plan would be to turn on all of your compiler's warnings. The warnings may miss some instances of undefined behavior, but they will catch a significant portion of them. Serious projects often require all (or at least -Wall) warnings to be checked; code that does not compile warning-free is quickly rejected. So you might as well learn to code warning-free now.

JaMiT
  • 14,422
  • 4
  • 15
  • 31
  • I think i get it. When i look up the definition of a segmentation fault, it says that it's an "error denoting that the software has attempted to access a restricted area of memory." So because the pointer variable was undefined, it did not possess a spot in memory, leading to the error. Did I get that right? – Anakita Smiles Sep 12 '19 at 00:54
  • @AnakitaSmiles That might be the right idea, but (at least) the terminology is wrong. A pointer does not possess memory; it points to memory. (A street sign that says "Library" and has an arrow pointing to the left does not own the library; it points to it.) Also, the problem is not "undefined" but "uninitialized". The line `int *p1;` defines the pointer without initializing it. The pointer's value is either random or zero, and the chance of that being a valid and unrestricted address is slim. – JaMiT Sep 13 '19 at 20:21