Hello Akim, > However the test case you provided does not compile, it still has > dependencies. > I can probably get it to work, but without the actual input that crashed your > parser, it would be useless. > > Is it possible to get that input? As a stream of tokens. If passing the code > here, publicly, is a problem, you can send it privately.
I am confused: Do you want my source code, the grammar that caused the crash, or both? If you want my source code, you'll be sorry you asked. It consists of 6 active sub-projects, all that just to send a line of text to the parser generator. It would be best for me to try and refit it to a "hello world" style app. Let me know if you prefer this option. For all the pain and suffering I put you through last year, I think I could do my part and help with this :) If all you want the actual input that caused the crash - I thought I was clear in my previous email: It crashes with the input: foo (*(*bar)())[] Also, re: >> I could remove this mess if we were able to make the %merge routines >> as members of the Parser class. hint hint - just a gentle nudge :) FWIW: I have my own workaround. I am only really bringing this up because I truly am impressed with Bison and the people behind it. And when I feel this way about a project, I tend to go a little overboard on issues that I feel are important. I really feel this is more of a blemish on what I consider an outstanding piece of work. Don't rush this on my account. As stated - I have my workaround. More formally: In the bison documentation, it states: "The Bison declaration ‘%define api.pure’ says that you want the parser to be reentrant." IMHO: The current method of writing merge routines contradicts the concept of api.pure. Either context is passed globally or through the arguments passed in. The latter is how I do it. And I feel that is an ugly hack. My proposal solves this issue in the most elegant and simplest way possible. My two cents worth, JotDot