<br><br><div class="gmail_quote">On Thu, Dec 8, 2011 at 11:04 PM, Francois Pichet <span dir="ltr"><<a href="mailto:pichet2000@gmail.com">pichet2000@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">On Thu, Dec 8, 2011 at 11:32 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> While writing some new tests I found a simple example that crashes under<br>
> clang's -verify. I'm a little concerned that this could hit real code<br>
> (especially in things like IDE plugins, etc that may be more interesting in<br>
> the spelling of tokens).<br>
><br>
> The repro is simple:<br>
><br>
> // \<br>
><br>
> this causes the verify mode to try to get the spelling of this comment<br>
> token. So long as the following line is empty, this crashes due to going<br>
> off-the-end inside the loop around Lexer.cpp:306-310. The<br>
> getCharAndSizeNoWarn is called just at the trailing '\' and it cannot<br>
> fulfill it's contract as there is no valid character for it to return.<br>
> Instead it returns a character off the end of the buffer & an increment<br>
> count that puts Ptr one unit /beyond/ 'End'. The loop will now never satisfy<br>
> its exit criteria & walks into memory that it shouldn't.<br>
><br>
> Just wondering if anyone has some nice ideas about how to fix this - I<br>
> assume it's rather perf critical so I don't want to go mucking with it too<br>
> ham-fistedly. The 'obvious' thing from my perspective would be to do the<br>
> walk forward at the previous character rather than when we're actually at<br>
> the '\', but this interferes with the fast path. The alternative seems to be<br>
> to have getCharAndSize[NoWarn] return a boolean about whether or not it was<br>
> able to read a char - but that might have similar problems.<br>
><br>
> Ideas welcome, otherwise I'll just have a tinker & see what sort of perf<br>
> results (any standard clang perf benchmarks would be nice)<br>
><br>
> - David<br>
><br>
<br>
</div></div>I saw this issue when calling clang -E on MFC code:<br>
<br>
<a href="http://llvm.org/bugs/show_bug.cgi?id=10153" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=10153</a><br>
</blockquote></div><br>Oh, thanks! - so it is a real(er) bug. Still interested in any opinions on a good fix.<br><br>- David<br>