0

Even after years of C, pointers still confuse me.

Are these two the same:

int *num;
someFunc(num)  

and

int num;
someFunc(&num);

Declaring a variable with * makes it a pointer, & turns a variable (momentarily) into a pointer?

littleadv
  • 20,100
  • 2
  • 36
  • 50
Marty
  • 5,926
  • 9
  • 53
  • 91

5 Answers5

2

No they are not the same. In the first case you have a pointer which is pointing to some random memory location (as you have not initialized it). In the second case, the pointer obtained in someFunc will be pointing to a valid location (the address of variable num).

Naveen
  • 74,600
  • 47
  • 176
  • 233
  • valid point. i was trying to keep it simple. after initialization, i take it they would indeed be the same? – Marty Apr 16 '12 at 04:39
  • Yes, if you properly initialize `int* num` then it will be same. – Naveen Apr 16 '12 at 04:41
  • so then `int* num = 8` would contain the memory address "8", or would contain a pointer to a memory address that held the value "8"? – Marty Apr 16 '12 at 04:54
  • no, `int* num = 8` will point to memory location `8` which will most probably an invalid memory location. To have a valid pointer you should point to an allocated block of memory. For example, `int x = 8; int *num = &x;`. Now `num` is *containing address of variable `x`* (for which the memory was allocated in statement `int x = 8`). Now if you dereference the pointer using `*num` it will fetch the content of the memory foe whose address it is holding. So `*num` will fetch the content of variable `x`. – Naveen Apr 16 '12 at 04:59
  • `int *num = 8;` is not even valid C; it will not compile. – R.. GitHub STOP HELPING ICE Apr 16 '12 at 05:18
  • @R.. That code is perfectly valid C and will compile, although some compilers may give warnings. Implicit typecasts between pointers and integers are allowed in C, although they will result in undefined behavior if the address isn't valid/aligned etc. – Lundin Apr 16 '12 at 08:12
  • Citation please? There's definitely no implicit conversion from integers to pointers for normal assignment or function calls, but perhaps initialization is a special case I missed. – R.. GitHub STOP HELPING ICE Apr 16 '12 at 09:57
2

They are the same in terms of the function call. However

The difference is....

int num is an actual integer, which you take the address of. Which can then be placed into a pointer

int *num is a pointer to an int, however, with your code as is, it does not point to an actual int that can hold a value.

so only the second example is working code.

first one would be working if...

int x;
int *num = &x;
someFunc(num)  

someFunc would look like

void someFunc(int *blah)
{
}

so basically int* num = &x is whats going on when you do the function call someFunc(&num) ie, its effectively just doing int* blah = &num

Keith Nicholas
  • 43,549
  • 15
  • 93
  • 156
1

The second passes the address of the integer num, a perfectly reasonable thing to do. The first passes whatever happens to be stored in the pointer num. That should be the address of an int, but in your example num is uninitialized and the address probably points to garbage (at best).

Joshua Green
  • 1,517
  • 1
  • 10
  • 14
1

& doesn't "turn a variable into a pointer", its an operator that returns the address of the variable. Which is, by definition, a pointer. Hence, no difference, the function someFunc receives a pointer value either way (in the first case it receives a copy the value of the pointer variable, in the second case it receives a copy of the return value of the operator &).

littleadv
  • 20,100
  • 2
  • 36
  • 50
1

In the first case, you're declaring num to be a pointer to an integer. In the second case num is an integer.

To the someFunc function, in both cases the argument passed is a pointer to integer. So, to print the value you'll need to dereference printf("%d\n", *num).

In both cases the value would be some garbage since you haven't initialized.

Hope that helps.

Update On FreeBSD I got segmentation fault with the first one since the pointer which is not initialized may have pointed to somewhere that it is not supposed to.

g13n
  • 3,218
  • 2
  • 24
  • 19