jtbandes added a comment. I can add some clarity but I can't claim to fully understand the whole program flow here yet, so my explanation is probably insufficient.
The overflow (underflow? but I think that means something specific to FP) is on line formerly-650: `EscapedNewlineColumn - Offset - 1`. This expression computes number of spaces required to place the `\` in the correct position. When EscapedNewlineColumn was 0, the Offset would end up being large enough for the computation on line 650 to roll over to a large value. Here is where my understanding is a bit fuzzier, and perhaps I should spend more time reading the code. When the alignment style is **not** `ENAS_DontAlign`, the function `alignEscapedNewlines()` adjusts the EscapedNewlineColumn of each line, **including blank lines**, which seems to result in EscapedNewlineColumn being always sufficiently large to do this subtraction without wrapping. (The approach of immediately `return;`ing for `ENAS_DontAlign`, committed in https://reviews.llvm.org/rL302428, was causing the EscapedNewlineColumn to be 0 here.) It is a possibility to simply check the EscapedNewlineColumn and do something different inside of appendNewlineText(). I'd be interested to hear your thoughts on which approach is better. Perhaps if I study the code some more there will a nice simplification will reveal itself to me... https://reviews.llvm.org/D36019 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
