[pmjordan]

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.

[PassTheAmmo]

I had to try it just because I wanted to know. With -Wall GCC says: pquest.c:279: warning: operation on 'fp' may be undefined

Not sure what 'may' means though

EDIT:

So to clarify, my suspicion is that the expression could mean either:

1)

    *fp = *fp >> 4;
    *fp++;

or

2)

    *fp = *(fp+1) >> 4;
    *fp++;

[BrandonM]

It is not the addressed value which is being incremented, but the pointer itself. There is no ambiguity.

[PassTheAmmo]

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 http://en.wikipedia.org/wiki/Sequence_point there is no sequence point because of assignment (only initialization which this is not)

Btw was it you that downvoted my comment?