Hi, I haven't been able to find a satisfactory answer yet!, but what would this code do?
So I guess the idea is , what happens to "p" at the termination of the function call? since its a stack variable, it gets popped, but the malloc'd memory is on the heap, which still persists, I think? and since you're returning the dereferenced variable, it should be good, right?Code:void main() { int a; a = foo(); printf("%d",a); } int foo() { int *p; p = malloc(1*sizeof(int)); *p = 5; return (*p); }
Last edited by squadeek; 06-14-2006 at 09:39 AM.
The program will print 5. What happens to p at the termination of the function call is irrelevant. The fact that the value 5 is stored on the heap is also irrelevant. You're not returning the address of something on the stack or the heap. You're just returning the value 5. BTW, yes, malloc()'d memory is valid until you free() it.
How many people did you actually ask this question?
P.S. Don't use void main() around here unless you want to be tarred and feathered.
Last edited by itsme86; 06-14-2006 at 09:52 AM.
If you understand what you're doing, you're not learning anything.
Pedantically speaking, nearly every line of that program has an issue.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
really? lay it on me man. I'm tryin to get better. and whats the deal with void main()? Well I've heard some people say that because p ceases to exist after the function termination, it'd cause an error.Originally Posted by Salem
If you return &p then it will cause an error(if you're lucky).
Also, use discriptive variable names.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
These people should either stop talking or actually try to know something about what they're discussing.
If you were returning the address of p, it still wouldn't be a problem because it's, like you said, on the heap; not the stack. The stack problems I see most often are something like:
That really is bad because buf is on the stack and when the function returns the contents of buf are left undefined and should not be used. If you made the function return the first character of the string (e.g. change the last line to return *buf;) it's no longer bad because you're not returning the address of something on the stack anymore, you're just returning whatever value happens to be there.Code:char *num_to_str(int num) { char buf[100]; sprintf(buf, "%d", num); return buf; }
If you understand what you're doing, you're not learning anything.
To start, I'll give you the benefit of the doubt and assume you left out the inclusion of stdio.h because you were trying to shorten your post and leave out unnessasary code.
Beyond that it won't compile because you need to prototype your functions before main() otherwise the compiler won't know what they are when you call them.
Lastly the FAQs should explain void main for you.
Sent from my iPadŽ
To explain precisely what would occur with your proposed code (assuming you were able to correct it for successful compilation), the foo() function would create a pointer variable 'p' which you point at a piece of heap memory. You then dereference the pointer and place the value 5 in that heap memory location. Finally, you dereference and return the value at the heap memory location (which is 5). Upon exiting foo(), the heap memory is still allocated, but now can never again be accessed (that's bad). In main() the value 5 is copied into variable 'a' and printed out.
No it wouldn't. It would end up casting (automatically) the address of the pointer to an integer, because that's what the function returns, and would return it as such. It would only be a problem if you tried to then convert that into an address, instead of an integer, and dereference it like a pointer.
Returning the pointer wouldn't cause a problem either, because they malloced space for it. It would simply return the pointer they've allocated space for. How do you think malloc works if you can't return pointers? Didn't I just have this same exact conversation with you a little while back? Well I suppose it could have been someone else...
Returning the address of a local variable is only really bad if you try to access that variable once it's gone out of scope, which is what you were trying to get across.
Quzah.
Hope is the first step on the road to disappointment.
That's all true. I was just hasty and did not fully explain what I ment by returning &p.
If you return &p(the address of char *p), and use it as the same type (char **), then try to dereference it, then you will, if lucky, get an error.
A good compiler will give you a warning if you're implicitly converting a pointer to an int.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
> void main()
void main is wrong, it should be int main
See the FAQ
> a = foo();
Call to unprototyped function, you assume it returns int.
With older compilers, all functions return int by default, but C is heading towards removing all the implicit 'int' behaviour. So now is a good time to be learning to prototype everything.
> printf("%d",a);
1. stdio.h is not included, so printf() is unprototyped
2. A \n at the end would be nicer IMO
No return 0; statement at end of program to signify program success.
> p = malloc(1*sizeof(int));
1. stdlib.h is not included, so function defaults to extern int malloc();
2. The implicit int to pointer conversion may be badly broken on your machine.
3. The FAQ (gotta love the FAQ) explains this.
4. You don't check the return result for NULL.
> *p = 5;
Ok, provided you have a NULL check before trying to dereference your pointer
> return (*p);
Instant memory leak, p goes out of scope, and along with it the reference to the memory you allocated.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
