bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++11 move semantics


From: Hans Åberg
Subject: Re: C++11 move semantics
Date: Sun, 11 Mar 2018 15:40:27 +0100

> On 11 Mar 2018, at 05:47, Rici Lake <address@hidden> wrote:
> 
>> On Mar 10, 2018 19:26, "Frank Heckenbach" <address@hidden> wrote:
>> 
>> Hans Åberg wrote:
>> 
>>>>>>>>>> so expensive. Also bison by default reserve()s 200 entries, and I
>>>>>>> 
>>>>>> Even if so, it's still a good idea to keep it, so vector basically
>>>>>> never actually needs to reallocate.
>>>>> 
>>>>> It depends on the grammar.
>>>> 
>>>> Do you actually have/know a use case with such a deep parse stack?
>>> 
>>> It would be hard to know either direction without checking. That
>>> limit may come from the C parser in the 1980-90s: modern computers
>>> are so powerful, one could expect anything.
>> 
>> Computers are powerful, sure, but can you think of an actual use
>> case of so deep nesting?
> 
> Here's an example which springs to mind: deeply nested right-associative
> operators. As you will see if you follow the link, the issue showed up in a
> real application and the problem was not obvious to the person it affected.
> 
> https://unix.stackexchange.com/questions/185923/eval-limitation-with-piped-commands/186446

This in fact a very good example in the context, as the parser stack may not be 
reduced in some cases. In the case of the C parser, the limit is set by 
YYMAXDEPTH with default 10000 as the link notes, which explains why it is the 
same on all platforms; cf. the Bison manual, sec. 5.10, "Memory Management". 
The C++ parser does not have that variable and limit, it seems.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]