Using pointers to pointers

Hello,

I am working on pointer to pointers. I know that a pointer is a variable that has a value that is an address. But I am getting confused with pointers to pointers in C.

I have a program that I have modified to try and understand this concept.

Is the parameter **source the address of the actual pointer?

What is the real purpose of having pointers to pointers? I have seen them alot by looking at source code, but not completely sure why someone would want to use one. What would an alternative be in using pointer to pointers in C programming?

Many thanks,

Code:

---

void find_integer(int **source)
{
    // int *pint = &INTEGER;

        printf("***************************\n");

    printf("*source = %d\n", *source);
        printf("**source = %d\n", **source);
        printf("Address of &*source %p\n", &*source);
        printf("Address of &source %p\n", &source);
        printf("Value pointed to *source %d\n", *source);
        //printf("Value pointed to **source %d\n", **source);
        printf("*************************\n\n");
   
        *source = &INTEGER;

    printf("*source = %p\n", *source);
    printf("**source = %d\n", **source);
}

int main()
{
    int *pint = &INTEGER;
    double *preal = NULL;
    int a = 3, b = 5;

        printf("Address of Integer %p\n", &INTEGER);
        printf("Address of pint %p\n\n", &pint);

    find_integer(&pint);
    return 0;
}

---

To modify something in a function, you need to have a pointer to whatever you are modifying. If you want to modify a pointer, then you need a pointer to pointer. I have occassionally seen triple-pointers (pointer to pointer to pointer), but it's rather rare.

--
Mats

By the way: You write

Code:

---

printf("Address of &*source %p\n", &*source);

---

but note that the & operator already means "address of". So I would write

Code:

---

printf("Address of *source %p\n", &*source);

---

.

Cheers,
Sander

Computer Programming: An Introduction for the Scientifically Inclined

Another thing: when printing pointers, not only should you use the %p format specifier as you have done, but you should cast the pointer to void*, e.g.,

Code:

---

printf("Address of *source %p\n", (void*)&*source);

---

Quote:

---

Originally Posted by Sander

By the way: You write

Code:

---

printf("Address of &*source %p\n", &*source);

---

but note that the & operator already means "address of". So I would write

Code:

---

printf("Address of *source %p\n", &*source);

---

.

---

Oh? And btw, &* just means "dereference" then "take the address of", so &*p = p.

And pointer to pointers are typically used for 2D arrays or when you need to pass a pointer to some function which wants to modify the original pointer.

Quote:

---

Originally Posted by Elysia

Oh?

---

You don't agree..?

--
Computer Programming: An Introduction for the Scientifically Inclined

Technically, it would be:
printf("Address of *source %p\n", source);
Because as I mentioned, &*p = p.

If we want to use Sander's suggestion, it would be:

Code:

---

printf("Address of *source %p\n", (void*)source);

---

Since p is the address of *p. On the other hand, I think it would be good for steve1_rm to also try out:

Code:

---

printf("Address of *source %p\n", (void*)&*source);

---

so as to be better convinced that they are equivalent (at least if source is valid and not NULL).

Ah, I missed the "address of" part, but the &* could removed, if you wanted. It really does nothing special (compiler would probably optimize it anyway, I guess).

Quote:

---

Originally Posted by Elysia

Ah, I missed the "address of" part, but the &* could removed, if you wanted. It really does nothing special (compiler would probably optimize it anyway, I guess).

---

Of course. The thread starter was doing all this stuff to get a better understanding of pointers, the address-of-operator, etc., and currently takes the word of his compiler over ours... I'm sure we've all been through this stage :-)

Also, I'm not sure the compiler is allowed to optimize it away. Is it promised that the special case that p is NULL breaks?

--
Computer Programming: An Introduction for the Scientifically Inclined

Quote:

---

Originally Posted by Sander

Also, I'm not sure the compiler is allowed to optimize it away. Is it promised that the special case that p is NULL breaks?

---

Dereferencing NULL is undefined behavior, not a mandatory failing condition. So it could optimize it.

Quote:

---

Originally Posted by robwhit

Dereferencing NULL is undefined behavior, not a mandatory failing condition. So it could optimize it.

---

Absolutely true. In fact, code that does offsetof() uses zero-derefences to get the offset of a member:

Code:

---

#define offsetof(T, field) (size_t)(&((T*)(0)->field))

---

The compiler should not actually access address zero in this case, but you have a pointer to T that is zero, which we take the address of.

--
Mats

That's a specific implementation of offsetof, right?

I think that would be undefined behavior if used in a program and not part of the implementation.

Something I read that helped me understand pointers goes something like this:

When you declare say an int, you say:

Code:

---

int var_name1;

---

When you declare a pointer to an int, you say:

Code:

---

int *var_name2;

---

The two look almost the same. If you ignore the "*" and think of it as part of the name of the variable, then you can use them the same way. So, where ever you may use "var_name1" in an expression, it would be just as valid to use "*var_name2". That is, both will give you the integer value stored in the memory referenced by the variable.

Once you take the "*" way from the pointer's identifier, then you are talking about the location in memory, not it's contents.

A little off topic from your original question, but hope it helps you read code better that uses pointers.

Quote:

---

Also, I'm not sure the compiler is allowed to optimize it away. Is it promised that the special case that p is NULL breaks?

---

In fact, in C99 the compiler is required to optimize it as such, meaning that applying &* to a null pointer is fine. I don't know where my C90 copy is, but the C89 draft I have doesn't require a compiler to do this.

Quote:

---

Originally Posted by jason_m

Something I read that helped me understand pointers goes something like this:

When you declare say an int, you say:

Code:

---

int var_name1;

---

When you declare a pointer to an int, you say:

Code:

---

int *var_name2;

---

The two look almost the same. If you ignore the "*" and think of it as part of the name of the variable, then you can use them the same way. So, where ever you may use "var_name1" in an expression, it would be just as valid to use "*var_name2". That is, both will give you the integer value stored in the memory referenced by the variable.

Once you take the "*" way from the pointer's identifier, then you are talking about the location in memory, not it's contents.

A little off topic from your original question, but hope it helps you read code better that uses pointers.

---

Something that really helps me understand pointers is to think of it as a type.

Code:

---

int n1; /* Integer */
int* n2; /* Pointer to integer */

---

The pointer is part of the type and goes on the left side.
If we remember that a pointer is a variable that holds an address, we would know that the name is just the address. By knowing the dereference principle (the one that says that to access the contents at location X), we should know that to get the value, just use *.

Quote:

---

In fact, in C99 the compiler is required to optimize it as such, meaning that applying &* to a null pointer is fine. I don't know where my C90 copy is, but the C89 draft I have doesn't require a compiler to do this.

---

That's true (section 6.5.3.2, paragraphs 3, 4 and footnote 83), but unfortunately I too do not have a copy of the C90 standard to confirm that &*NULL results in undefined behaviour according to that set of rules.

Quote:

---

In fact, in C99 the compiler is required to optimize it as such, meaning that applying &* to a null pointer is fine. I don't know where my C90 copy is, but the C89 draft I have doesn't require a compiler to do this.

---

That's true (section 6.5.3.2, paragraphs 3, 4 and footnote 83), but unfortunately I too do not have a copy of the C90 standard to confirm that &*NULL results in undefined behaviour according to that set of rules.

Quote:

---

The two look almost the same. If you ignore the "*" and think of it as part of the name of the variable, then you can use them the same way. So, where ever you may use "var_name1" in an expression, it would be just as valid to use "*var_name2". That is, both will give you the integer value stored in the memory referenced by the variable.

---

Yes, that is what Stroustrup means when he states: "A ``typical C programmer'' writes ``int *p;'' and explains it ``*p is what is the int'' emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the * binds to the name p in the grammar."

That said, there is an inconsistency when taking the syntax argument as is, since:

Code:

---

int var_name1 = x;

---

would generally become:

Code:

---

int *var_name2 = &x;

---

not:

Code:

---

int *var_name2 = x;

---

Consequently, I am influenced by my C++ background to talk about type instead of syntax, as in "A ``typical C++ programmer'' writes ``int* p;'' and explains it ``p is a pointer to an int'' emphasizing type. Indeed the type of p is int*."

Quote:

---

Originally Posted by robwhit

That's a specific implementation of offsetof, right?

I think that would be undefined behavior if used in a program and not part of the implementation.

---

Yes, it is implementation dependand, but I know this implementation works in several different compilers, including gcc and MS VC.

Edit: In fact I don't think I've ever seen a DIFFERENT offsetof implementation (aside from the fact that I was paraphrasing the implementation itself), but I'm sure someone will come up with one that doesn't follow this pattern if we wait long enough.

--
Mats

EDIT:
Removed. Posted incorrect code, tried it out on my machine to verify, wreaked havoc. Oops