Looking for explanation as to why, using pointer arithmetic, pointer can be incremented as ptr +1, but cannot be incremented as ptr++, as in the following code:
#include <stdio.h>

int main(void){

int N = 7;
int *ptr1;
int array[] = {10, 20, 30, 40, 50, 60, 70};
//ptr1 = array;
ptr1 = &array[0];

while(ptr1 < &array[N]){
printf("*ptr1 = %d\n", *ptr1); //this works fine
ptr1 = ptr1 +1;

printf("*ptr1 = %d\n", *ptr1); //this doesn't
ptr1 = ptr1++;
}

return 0;

}

Did a quick google search, and I found this.

(One question that comes up is whether the expression *p++ increments p or what it points to. The answer is that it increments p. To increment what p points to, you can use (*p)++.)

http://www.eskimo.com/~scs/cclass/notes/sx10b.html

This is wrong, its result is compiler/platform/random-dependent. If you want to increment ptr1, pick one of the following three:

1 members found this post helpful.

NevemTeve is right. I didn't even catch that. You can't use ptr1 = ptr1++; and expect a correct answer because the ++ is essentially ptr1 = ptr1 + 1; so you would just want to use ptr1++; like NevemTeve suggests.

Another one you could use is:

Just remember to use what will make your code the most readable / maintainable.

2 members found this post helpful.

NevemTeve gave you most of the answer. For the full answer read this:
http://c-faq.com/expr/seqpoints.html
especially the explanation and examples of the rule: "Between the previous and next sequence point an object shall have its stored value modified at most once"

1 members found this post helpful.

Thanks again to all of you. Those eskimo notes seem terrific to answer many of my questions without further dependence upon your time. (seems like many others have had similar questions to mine.)
If I read that seg on 'sequence point' 5 or 6 more times I may even get to really understand it!

I don't know if that second rule is comprehensible:
"the prior value shall be accessed only to determine the value to be stored".

I understand what that rule is there to restrict, so I can fit the English phrase to the intent of the rule. But only because I already knew the intent of the rule. If you didn't know that intent some other way, I doubt you could parse it from that sentence:

a[i++] = 5;
Looks to me like the prior value of i is used as the index into a[], which that rule seems to prohibit. But it isn't really the prior value of i being used. It is the result of i++ (which happens to equal that prior value) being used.

The English could also be considered ambiguous regarding "the value to be stored" in an expression storing more than one value (correctly into different places). Once you know what it means, you can parse that English as meaning that. But in my opinion, it fails to communicate what it means.

The real intent is you can't have a read and a write of the same location in ambiguous sequence to each other. Almost everything between two sequence points is in ambiguous sequence, except where that is impossible, such as storing a value before computing it.

1 members found this post helpful.

Thanks again, JF. Your comment corroborates what I often say about programming texts, etc: "they are mostly written for those who already know programming". After my second (careful) reading of that thread, I at least now realize that statements such as i++; are, in themselves, a "full expression", which explains why my i = i++ makes no sense. That's certainly an improvement.

i++ can be a "full expression". It doesn't need to be. The following makes sense:
In that, i++ is a sub expression, not a full expression.

The meaning of i++ makes the above statement equivalent to three steps:
A) temp = i
B) i = temp+1
C) x = temp
The meaning of i++ also requires that A occurs before B and that A occurs before C. But nothing about the language says whether B occurs before or after C.

If i and x are different variables, then the final result does not depend on the relative sequence of steps B and C.

If i and x were the same variable, then the result depends on that sequence. Once the result depends on that sequence, the optimization rules say the result is completely undefined. It is not just undefined which sequence steps B and C occur in. An optimizer might (and sometimes does) generate code that produces results that don't fit either sequence.

1 members found this post helpful.

Yes, I get it. I only made my reply brief, but the FAQ was clear that something like would also be a full expression that would be acceptable.
Glad you mentioned what a "sub-expression" is, 'cause that wasn't in their glossary.