Re: Bug in glr2.cc

[Jot Dot]

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