No one has been able to answer this yet!!

This is a discussion on No one has been able to answer this yet!! within the C Programming forums, part of the General Programming Boards category; Hi, I haven't been able to find a satisfactory answer yet!, but what would this code do? Code: void main() ...

  1. #1
    Registered User
    Join Date
    Jun 2006
    Posts
    2

    No one has been able to answer this yet!!

    Hi, I haven't been able to find a satisfactory answer yet!, but what would this code do?



    Code:
    void main()
    {
        int a;
    
        a = foo();
    
        printf("%d",a);
    
    }
    
    
    int foo()
    {
    
       int *p;
       
       p = malloc(1*sizeof(int));
    
       *p = 5;
    
       return (*p);
    
    }
    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?
    Last edited by squadeek; 06-14-2006 at 09:39 AM.

  2. #2
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    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.

  3. #3
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,442
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #4
    Registered User
    Join Date
    Jun 2006
    Posts
    2

    Thanks...

    Quote Originally Posted by Salem
    Pedantically speaking, nearly every line of that program has an issue.
    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.

  5. #5
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    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.

  6. #6
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    Quote Originally Posted by squadeek
    Well I've heard some people say that because p ceases to exist after the function termination, it'd cause an error.
    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:
    Code:
    char *num_to_str(int num)
    {
      char buf[100];
    
      sprintf(buf, "%d", num);
      return buf;
    }
    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.
    If you understand what you're doing, you're not learning anything.

  7. #7
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,066
    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Ž

  8. #8
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856
    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.

  9. #9
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by King Mir
    If you return &p then it will cause an error(if you're lucky).
    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.

  10. #10
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    Quote Originally Posted by quzah
    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.
    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.

  11. #11
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,442
    > 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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Looking for constructive criticism
    By wd_kendrick in forum C Programming
    Replies: 16
    Last Post: 05-28-2008, 09:42 AM
  2. One quick question...
    By Kross7 in forum C++ Programming
    Replies: 10
    Last Post: 04-13-2007, 09:50 PM
  3. Tic Tac Toe program...
    By Kross7 in forum C++ Programming
    Replies: 12
    Last Post: 04-12-2007, 03:25 PM
  4. Game Programming FAQ
    By TechWins in forum Game Programming
    Replies: 5
    Last Post: 09-29-2004, 02:00 AM
  5. code help :)
    By Unregistered in forum C Programming
    Replies: 4
    Last Post: 02-28-2002, 12:12 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21