[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in glr2.cc
Re: Bug in glr2.cc
Sat, 15 Jan 2022 03:30:38 -0700 (MST)
> However the test case you provided does not compile, it still has
> 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,
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:
>> 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.
In the bison documentation, it states:
"The Bison declaration ‘%define api.pure’ says that you want the parser to be
IMHO: The current method of writing merge routines contradicts the concept of
Either context is passed globally or through the arguments passed in. The
how I do it. And I feel that is an ugly hack. My proposal solves this issue in
most elegant and simplest way possible.
My two cents worth,