[cfe-dev] Endless operator-> chain causing infinite loop

Richard Smith richard at metafoo.co.uk
Wed Oct 23 11:27:10 PDT 2013


On Wed, Oct 23, 2013 at 6:06 AM, Rahul Jain <1989.rahuljain at gmail.com>wrote:

> Hi Richard / Karen,
>
> Thanks for making things clearer.
> Now how do we go about handling this sort of behavior?
>
> Do we throw an error message just like g++ does? Wont it be better to
> print an error message instead of an infinite loop?
>

We don't know the loop is infinite, but we should probably give up after
some number of iterations.


> Also if you could please elaborate a bit on how we can "limit the number
> of times we go around the loop looking for an overloaded operator->
> in Sema::
> ActOnStartCXXMemberReference" ?
>

Add a counter to the "while (BaseType->isRecordType())" loop. Bail out with
a diagnostic if it hits the limit.


> Thanks,
> Rahul
>
>
>
>
> On Wed, Oct 23, 2013 at 3:30 AM, Karen Shaeffer <shaeffer at neuralscape.com>wrote:
>
>> On Tue, Oct 22, 2013 at 02:54:08PM -0700, Richard Smith wrote:
>> > On Tue, Oct 22, 2013 at 2:03 PM, Karen Shaeffer <
>> shaeffer at neuralscape.com>wrote:
>> >
>> > > On Tue, Oct 22, 2013 at 12:14:25PM -0700, Richard Smith wrote:
>> > > > On Tue, Oct 22, 2013 at 2:45 AM, Rahul Jain <
>> 1989.rahuljain at gmail.com
>> > > >wrote:
>> > > >
>> > > > >
>> > > > > Hi all,
>> > > > >
>> > > > > clang version 3.4 (192772)
>> > > > >
>> > > > > This is with respect to the following gcc testsuite TC:
>> > > > >
>> > > > > template< int n >
>> > > > > struct a {
>> > > > >     a< n+1 > operator->()
>> > > > >         {
>> > > > >         return a< n+1 >();
>> > > > >         }
>> > > > > };
>> > > > >
>> > > > > int main() {
>> > > > >     a<0>()->x;
>> > > > > }
>> > > > >
>> > > > >
>> > > > > This TC goes into an infinite loop when compiled. Ideally it
>> should
>> > > throw
>> > > > > the error
>> > > > > recursive template instantiation exceeded maximum depth of 256.
>> > > > >
>> > > >
>> > > > That's not the right behavior; there's no recursive template
>> > > instantiation
>> > > > here. Each operator-> is instantiated from within the context of
>> 'main',
>> > > > not from within some other instantiation.
>> > > >
>> > > > If we want to limit this, we should put a limit on the number of
>> times we
>> > > > go around the loop looking for an overloaded operator->
>> > > > in Sema::ActOnStartCXXMemberReference. However, I've seen people
>> use this
>> > > > in practice in template metaprogramming to get around the recursive
>> > > > template instantiation depth, so this might break existing code.
>> > >
>> > > Hi Richard,
>> > >
>> > > Just checked, and g++-4.7.2 doesn't give a 'recusive template
>> > > instantiation' error.
>> > > The error is:
>> > >
>> > > error: template instantiation depth exceeds maximum of 900 (use
>> > > -ftemplate-depth= to increase the maximum) instantiating ‘a<(n + 1)>
>> > > a<n>::operator->() [with int n = 900]’
>> > >
>> >
>> > This is their recursive template instantiation error. I'm not sure why
>> they
>> > chose to diagnose this problem in that way; there is no recursive
>> > instantiation here. The loop is in [over.ref](13.5.6)p1:
>> >
>> > "An expression x->m is interpreted as (x.operator->())->m for a class
>> > object x of type T if T::operator->() exists and if the operator is
>> > selected as the best match function by the overload resolution
>> mechanism."
>> >
>> > This rule gets applied repeatedly, outside of any template
>> instantiation.
>> >
>> >
>> > > In the standard at [temp.inst]
>> > >
>> >
>> > > <14.7.1 note d>
>> > > There is an implementation-defined quantity that specifies the limit
>> on
>> > > the total depth
>> > > of recursive instantiations, which could involve more than one
>> template.
>> > > The result of an
>> > > infinite recursion in instantiation is undefined.
>> > >
>> >
>> > This is not what's happening in this case.
>>
>> Hi Richard,
>> I understand it is not what is happening. I just included the <14.7.2
>> note 15>
>> for clarity. I think the g++ error message is crystal clear. And the
>> practicality
>> of it is obvious.
>>
>> Thanks for your comments.
>>
>> enjoy,
>> Karen
>> --
>> Karen Shaeffer                 Be aware: If you see an obstacle in your
>> path,
>> Neuralscape Services           that obstacle is your path.        Zen
>> proverb
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131023/a5ffd86a/attachment.html>


More information about the cfe-dev mailing list