According to the Standard: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored."
What the second sentence says, is this: if an object is written to within a full expression, any and all accesses to it within the same expression must be directly involved in the computation of the value to be written. This rule effectively constrains legal expressions to those in which the accesses demonstrably precede the modification. For example, the old standby i = i + 1 is allowed, because the access of i is used to determine i's final value. The example
*(fp++) = *fp >> 4; /* redundant parentheses */
is disallowed because one of the accesses of fp (the one in *fp) has nothing to do with the value which ends up being stored in fp (which happens over in fp++), and so there's no good way to define - either for our understanding or the compiler's - whether the access should take place before or after the modified value is stored.
Hence, the quoted statement does invoke undefined behaviour.
The rule you're alluding to is that you mustn't modify the same value more than once between sequence points. I don't think that rule applies here, as it's modifying fp (a pointer value) and then the memory location at the address of fp's original value: the increment operator has higher precedence than dereferencing (which is of course an arbitrary rule I happen to have memorised, and many have not). The right hand side has no side effects.
It's certainly confusing code, but I'm fairly sure the outcome is well-defined. That doesn't mean it's good code: I'd never write it like that. I find this far easier to understand, and that's how I'd write it in practice:
*fp >>= 4;
++fp;
The postfix while condition isn't one of my favourites either, but not quite as confusing.
I never claimed that the addressed value would be incremented, and that is not what is being discussed here, even though that too would have been a problem.
The thing is, at some point the compiler must calculate the address where to store the value. The question is then if there is a sequence point between calculating the data to store and the address which to store to. Otherwise there is ambiguity and the result is undefined.
According to the Standard: "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored."
What the second sentence says, is this: if an object is written to within a full expression, any and all accesses to it within the same expression must be directly involved in the computation of the value to be written. This rule effectively constrains legal expressions to those in which the accesses demonstrably precede the modification. For example, the old standby i = i + 1 is allowed, because the access of i is used to determine i's final value. The example
is disallowed because one of the accesses of fp (the one in *fp) has nothing to do with the value which ends up being stored in fp (which happens over in fp++), and so there's no good way to define - either for our understanding or the compiler's - whether the access should take place before or after the modified value is stored.Hence, the quoted statement does invoke undefined behaviour.