It would be lovely if those whitespace changes could be kept separate from the actual functional changes; makes it a lot easier on reviewers, and also helps figure out merge conflicts down the road.

This moves the allocation before the ASSERT; this is potentially wasteful (though only cosmetically so), because when the assert doesn't hold, the memory will still have been allocated.

I found the old loop logic easier to follow than this. Either way, you have two variables that go into effective loop conditions (ch and i); the old version had ch as the principal loop condition (signalling the intent "loop until you find a double quote") and tracks i as a counter on the side; the new version has i as the principal loop condition (signalling the intent "keep incrementing a size counter forever"), and then side-aborts the loop based ch. I would say that the former is closer to the actual intent here, and the latter only adds confusion.

Is there a strong, compelling reason to write it like this?