Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 6 of 6
  1. #1
    Supreme Master coder! abduraooft's Avatar
    Join Date
    Mar 2007
    Location
    N/A
    Posts
    14,864
    Thanks
    160
    Thanked 2,224 Times in 2,211 Posts

    Please explain the output of this simple C code

    The following program gives me 100 and 99.
    Code:
    #include <stdio.h>
    
    void print(int *p,int *q){
    printf("%d \n %d",*p,*q);
    }
    void main(){
    static int arr[]={97,98,99,100,101,102,103};
    static int *ptr=arr+1;
    print(++ptr,++ptr);
    }
    Please explain me how that 99 comes there.

    Thanks
    The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)

  • #2
    Regular Coder ralph l mayo's Avatar
    Join Date
    Nov 2005
    Posts
    951
    Thanks
    1
    Thanked 31 Times in 29 Posts
    Last edited by ralph l mayo; 07-14-2009 at 04:15 PM. Reason: change stupid expert sexchange link to google cache

  • Users who have thanked ralph l mayo for this post:

    abduraooft (07-14-2009)

  • #3
    Senior Coder tomws's Avatar
    Join Date
    Nov 2007
    Location
    Arkansas
    Posts
    2,644
    Thanks
    29
    Thanked 330 Times in 326 Posts
    And so for this specific implementation, it looks like it's stacking the pointer location and then rolling back as the printf is evaluated. Is that an accurate observation (again, for this implementation)?
    Are you a Help Vampire?

  • #4
    Supreme Master coder! abduraooft's Avatar
    Join Date
    Mar 2007
    Location
    N/A
    Posts
    14,864
    Thanks
    160
    Thanked 2,224 Times in 2,211 Posts
    Thanks for that link (which gives many other related links)
    But, Isn't
    Code:
     int i=0;
      CPrint(++i,++i);
    equivalent to
    Code:
    int i=0;
    i++;i++;
      CPrint(i,i);
    ?
    ie, evaluate the arguments first(in whatever order it likes) and then call the function?
    Or is it calling the function twice(some how by the internal implementation) for passing the arguments one by one?

    Is this behaviour exists only in C and C++?
    The Dream is not what you see in sleep; Dream is the thing which doesn't let you sleep. --(Dr. APJ. Abdul Kalam)

  • #5
    Regular Coder ralph l mayo's Avatar
    Join Date
    Nov 2005
    Posts
    951
    Thanks
    1
    Thanked 31 Times in 29 Posts
    The unspecified order of argument evaluation is only on facet of the problem with that line of code. The expanded second version *does* have defined behavior, because it introduces sequence points between the increment ops.

    Even if the language guaranteed left-to-right evaluation of function arguments, since side-effects of ++ are not resolved until the next sequence point, there are still (at least) two possibilities:
    Code:
    // compiler fully-evaluates arguments as soon as possible
    CPrint(++i, ++i) ==  /* pseudocode */ args[0] = ++i; args[1] = ++i; CPrint(args[0], args[1])
    // if i is 2, cprint is passed 3, 4
    
    // compiler decides to "optimize" by defering incrementing 
    // the variable until just before the sequence point
    CPrint(++i, ++i) == /* pseudocode */ CPrint(i + 1, i + 1); i += 2;
    // if i is 2, cprint is passed 3, 3
    Once the sequence point is hit i is always going to hold a predictable value, but before then if you write twice to the same variable there's no guarantee that either have happened yet.

    edit:
    oops, the second pseudo-code is misleading because there is a sequence point before the function is entered. What it's really doing is setting both args to i + 1, incrementing i by 2, and *then* calling the function. The difference isn't really consequential because the function doesn't have a pointer to i anyway.
    Last edited by ralph l mayo; 07-14-2009 at 06:07 PM.

  • #6
    Rockstar Coder
    Join Date
    Jun 2002
    Location
    USA
    Posts
    9,074
    Thanks
    1
    Thanked 328 Times in 324 Posts
    You could also have your compiler generate the listing file for that code and you could see how it went about implementing it in assembly. Might be kind of interesting.
    OracleGuy

  • Users who have thanked oracleguy for this post:

    abduraooft (07-15-2009)


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •