<p dir="ltr">This is PR9619 and duplicates. There are really two problems here: we allow arbitrarily complex types to be created then hit a stack overflow when processing them, and we don't restrict the depth of operator-> chains we will follow (except when there is a cycle).</p>

<div class="gmail_quote">On 23 Feb 2013 20:56, "Sean Silva" <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Slide 11 of <<a href="http://miek.nl/downloads/2010/c++-talk.pdf" target="_blank">http://miek.nl/downloads/2010/c++-talk.pdf</a>> shows the<br>
following code as sending the compiler into an infloop:<br>
<br>
template<class T> struct Loop { Loop<T*> operator->(); };<br>
Loop<int> i, j = i->hooray;<br>
<br>
I just verified that clang does go into an infloop for this and<br>
clang's resident memory starts growing without bound. Is there some<br>
way for us to detect this and properly diagnose?<br>
<br>
Also, I'll file a PR to track this unless somebody knows if we already<br>
have a PR for it or we deliberately don't do anything about this<br>
behavior.<br>
<br>
-- Sean Silva<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>