Or does X=2 and Y=14/3?
Or does X=2 and Y=14/3?
Last edited by ÉireKarl; 05-01-2010 at 12:31 PM.
Hint: The value of argument P passed to function func() doesn't change after func executes.
Question to think about: Why?
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
Because it doesn't have an address to point to?Originally Posted by claudiu
Close, because you are not passing the address of an integer for P, just a value, the value gets updated during the lifetime of func() but this doesn't change the value of the variable you passed as an argument from main. The exact opposite is true for Q.
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
*All* function arguments are passed "by value". When you pass a pointer, as in the exam question, that pointer is a local variable to the function called func(). This pointer will cease to exist after the function 'ends'. So what actually gets changed back in main() is what the pointer is pointing to and not the pointer itself.
Last edited by Overworked_PhD; 05-01-2010 at 03:35 PM.
I see what you are getting at and I will admit that I have been somewhat unclear in my explanation. You are correct in that even when you pass a pointer to a function you basically pass the value of the address the pointer is pointing at. However, note that you are wrong about the last statement.
"So what actually gets changed back in main() is what the pointer is pointing to and not the pointer itself".
The pointer is not pointing to something else, it is pointing to the same address, however the data contained at that address has changed.
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
What the pointer is pointing to refers to the contents of the object, and not the address. So let's say I have
int x = 3;
int *p = &x;
p pointing at x would look like
x <----p
Now when I dereference this pointer, I'm getting what p points to. In this case, it would be 3. If I had a pointer to a pointer, then what the pointer is pointer to would refer to the pointer (ie the address).
No, pointers don't point to values, they point to locations in memory.
Read the FAQ before posting.
Cprogramming.com Tutorial: Pointers
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
Because that value is placed on the function's stack, which means it is a copy of the original. When you change a copy of something (say a document), that does not change the original at all. To do that, you have to pass a pointer to where the original is stored, as Overworked_Phd says.Because it doesn't have an address to point to?
While I don't think using the phrase "pass by reference" with C will do on an exam, many people do this informally and it does make sense: you want to pass a reference to the variable via a pointer (altho technically what you are doing is passing the value of the pointer, which is an address, the address of the variable).
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
Okay, technically I dereference p (which is a pointer). Also pointers do have values. If I had something like...
The value of head_ref would be struct node* (not the address).Code:struct node *head = malloc(sizeof(struct node)); struct node **head_ref = &head;
Psstt... I got this example from Dr. Sosman over at SUN.
Last edited by Overworked_PhD; 05-01-2010 at 04:16 PM.
NO, that is so wrong it's insane.
Why don't you ask Santa Clause instead what value does a void* point to?
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
Nice try editing a wrong post. Now it's even worse. Hahaha that just proves how much C you actually know. These people communicating with you should start asking for tuition money for teaching you C. Also, note that I don't believe that anyone with a PhD working at Sun would be able to produce such an incomplete and nonsensical example.
1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
3. Get rid of conio.h and other antiquated DOS crap headers.
4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.
I guess I tend to believe Dr. Sosman over you. Maybe this is because the guy used to be a former Mathematics Professor before joining SUN as a Senior Engineer. Maybe it's because he holds a Ph.D. Or maybe it's because he has several academic publications.
So go back and ask him what in the name of all that is good
"The value of head_ref would be struct node* (not the address)."
even means. Or for once, man up and admit that you completely garbled whatever he was trying to tell you in an e-mail and posted it here in an attempt to look like the star but completely botched it.
Here is the actual post..
assignment from incompatible pointer type - comp.lang.c | Google Groups
" Right. Pointers in C have types; different types of pointers
aim at different types of targets. The local_Cp element is a
pointer to `double', and can legitimately aim at a `double' object
(or can be null). The localC element is a pointer to `double*',
that is, a pointer to another pointer that in turn can aim at a
`double':
local_Cp ----> [ 3.14159 ]
localC ----> [ double* ] ----> [ 2.71828 ]
The code tries to aim localC at a `double' (the same `double'
local_Cp aims at), but since localC can only target `double*'
objects, not `double' objects, the assignment is incorrect.
> Coming from the Fortran 95 world, I'm not too familiar with pointers yet...
> but I think the original author of the code made a mistake here, and it
> should probably be fixed as
> media->localC =&(media->local_Cp);
> Am I correct?
You're correct in that the r.h.s. is now the proper type for
the l.h.s. to aim at. It's impossible to tell from the snippet
whether that's what it *should* aim at.
> Or could the way the original author has written the code be
> really intentional?
It was almost certainly intended, but the intent was almost
certainly mistaken. In exactly what way, I can't tell.
"
