title: does the following pre-increment expression really result in unsequenced modification?
body: <p>I have a legacy code performing double buffering with this instruction:</p>
  <pre><code>bufferIndex = ++bufferIndex &amp; 1;
  </code></pre>
  <p>clang warns about unsequenced modification order of bufferIndex</p>
  <blockquote>
  <p>warning: multiple unsequenced modifications to 'bufferIndex' [-Wunsequenced]</p>
  </blockquote>
  <p>In the doubt, I would avoid such construct, especially since knowing that the bufferIndex has been appropriately initialized to either 0 or 1, this flip/flop could have been written more simply:</p>
  <pre><code>bufferIndex ^= 1;
  </code></pre>
  <p>Even without a doubt, I would avoid such pre-increment construct so that I don't cause confusion in my rewiewers mind, and so that I don't generate brainstorming warnings uselessly.<br>
  But that's not my point. My point is that I want to understand if unsequenced modification is possibly true here for my own culture.</p>
  <p>Is the evaluation order really undefined in this case, or is the warning a bit abusive?</p>
  <p>Note: it's not the same case as <a href="https://stackoverflow.com/questions/66294102/unsequenced-modification-warning">Unsequenced modification warning</a> where the variable clearly appear twice in an unsequenced manner, nor in the other possible duplicates suggested by SO (unless I overlooked).</p>
  <p>It's not at all obvious that this applies to this case of assignment operator = to my understanding, since expression has to be evaluated BEFORE being assigned to, and since the sole side effect is pre-increment and will necessarily happen sometime during evaluation and before assignment.</p>