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

[David Blaikie]

On Wed, Oct 23, 2013 at 11:27 AM, Richard Smith <richard at metafoo.co.uk>wrote:

> 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.
>

Pedantry, just for fun - should this be added to the implementation limits
in the C++ standard?

- David


>
>
>>  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
>>>
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131023/eb3bf90f/attachment.html>