> On 11 Mar 2018, at 05:47, Rici Lake <ricil...@gmail.com> wrote: > >> On Mar 10, 2018 19:26, "Frank Heckenbach" <f.heckenb...@fh-soft.de> 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.
