The old code updated the `eor` variable in the third field of the for loop, after the increment of the loop variable, `i`, to the then-value of `i`. The variable was initialized as zero. This is a very roundabout way of doing things, because, if you look at it from the right angle, `eor` will always have the value 'i' has when entering the loop body. Proof: - First round: i = 0, eor = 0. So i == eor. Check. - Next round: i = 1 + whatever value `i` had at the end of the previous iteration. eor := i, so i == eor. Check. So rewrite the code to create `eor` at the beginning of the loop body, with the then-value of 'i'. This allows marking it const, too, and scoping it correctly, drastically improving readability. The tighter scoping runs afoul of the assert(eor == string.size()) after the loop, which, however, is pointless, because it's true by construction: the loop has no break statement, so the only way it can be exited is by failing the loop condition. At that point, eor := i and i == string.size(), so eor == string.size(). Partially reverts 3df159ba174c1775a0e77d2305a639eeab1ea71d, but the loose scope of the variable was present even before that. Pick-to: 6.10 6.8 6.5 Change-Id: I983aef94caa8a3bc09ab378b8bb9bb4a18dabeb4 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>