#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    5
    Rep Power
    0

    Confusion over Pointer


    Code:
     void print(int *a,int *b,int *c,int *d,int *e)
    {
    	printf("%d - %d - %d - %d - %d \n", *a,*b,*c,*d,*e);
    }
    
    int main()
    {
    	int a[]={97,98,99,100,101,102,103,104};
    	int *ptr=a+1;
    	
    	
        print(ptr,ptr--,ptr,ptr++,++ptr);
    	
        
    	return 0;
    }
    The code gives the following output:
    99 - 100 - 99 - 99 - 99

    So why is the output like that? How the incrimination happening in here?
  2. #2
  3. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    The output is that because of the code that the compiler generated. Why, did you expect the output to be something different? What did you expect the output to be, and why?

    Also, why are you doing something so stupid as to change and use a variable repeatedly within the same sequence point?

    BTW, the Pascal order of evaluating the arguments of a function is from left to right (ie, the first argument first, the second second, etc), whereas the C order is from right to left (the last one first, etc). This is normally unimportant, but in Windows uses Pascal order so in SDK programming you need to specify the order with the PASCAL qualifier (Programming Windows 3.1 by Charles Petzold, pp 26, 28). I cannot find this information in the C standard (ANSI/ISO 9899-1990), though 6.3.2.2 says:
    The order of evaluation of the function designator, the arguments, and the subexpressions within the arguments is unspecified, but there is a sequence point before the actual call.
    PS
    BTW, when I run it I get:
    99 - 100 - 100 - 99 - 99
    That is exactly what I got when I stepped through it with pencil and paper.

    PPS
    In Assembly Language: Programming for the IBM PC Family (3rd ed) by William B. Jones, page 376, he gives the rational for the right-to-left order in C argument evaluation as being because of functions with a variable number of parameters, such as printf, such that pushing them in left-to-right Pascal order would leave us unable to tell where the first parameter is. As I recall, Pascal does not allow variable numbers of arguments, so the procedure always knows how many parameters it has, so it can always find the first one.
    Last edited by dwise1_aol; May 9th, 2013 at 01:48 PM.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    May 2013
    Posts
    5
    Rep Power
    0
    Well, if you don't do stupid things sometimes you'll never become a better programmer, so the code was see to how pointer increment works if passing to function and it's evaluation order, if you think you are smartass then don't reply.
  6. #4
  7. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally Posted by C-Nerd
    Well, if you don't do stupid things sometimes you'll never become a better programmer, so the code was see to how pointer increment works if passing to function and it's evaluation order, if you think you are smartass then don't reply.
    If your head is wedged so far up your rectum that you will ignore answers to your questions, then don't bother to post.

    Plus, WE ARE NOT MIND-READERS! If you want us to tell you why an output is not what you expected it to be, then tell us what you expected it to be!

    Now please pull your head out and respond to the answers, jerk!

    Comments on this post

    • ptr2void agrees : Bad code is bad code. Period.
  8. #5
  9. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,145
    Rep Power
    2222
    Originally Posted by C-Nerd
    Well, if you don't do stupid things sometimes you'll never become a better programmer, so the code was see to how pointer increment works if passing to function and it's evaluation order, if you think you are smartass then don't reply.
    And because your delicate feelings were hurt, it appears that you completely overlooked the important information I gave you there.

    The only thing you discovered about the order in which function arguments are evaluated is the order used by that one specific compiler you are using. What I was telling you is that that order is not defined by the language standard. That means that a different compiler could very well order them in the opposite direction. Which ultimately means that you cannot depend on the order in which a function's arguments are evaluated, because that order is not defined. And depending on undefined behavior is just plain stupid.

    We get a lot of such questions here because some instructors seem to have the odd idea that there's pedagogic value in having students figure out why bad, stupid code doesn't work as expected. Usually it involves pre/post-incrementing/decrementing a variable multiple times in the same expression, just as you had done with that pointer in the function arguments.

    For example, in Java class our instructor presented us with this code and asked us to calculate the value of y:
    Code:
    x = 3;
        y = x + x * ++x;
        System.out.println("x = "+x+"; x + x * ++x = "+y+"\n");
    Applying my training, which involved expression evaluation with a stack, I arrived at an answer of 15. The instructor came up with an answer of 20 and was then very surprised when he ran the program and it arrived at 15 instead of 20. During the week, I tried the same expression in a number of different languages, most of them C-ish, and found that some gave the one answer while others gave the other. The crucial difference seemed to be whether that language/compiler used a stack to evaluate expressions, which the Java virtual machine does.

    And, yet again, the bottom line is that the behavior is not defined, so writing code like that is a stupid thing to do. My write-up that I emailed to my instructor is posted at http://pgm.dwise1.net/misc/test.html; BTW, that was before I had learned the term, sequence point, which really describes what's happening.


    As I already mentioned, a forum member's tag-line likens the use of undefined behavior to dancing barefoot on broken glass. Depending on undefined behavior is stupid. Yes, you were conducting an experiment (which you should have mentioned up-front), but you missed the fact that the behavior that you discovered is just a convention used with x86 processors and is not defined by the language standard and hence cannot be depended on.

IMN logo majestic logo threadwatch logo seochat tools logo