Re: text is not parsed correctly due to shift/reduce conflict

[Christian Schoenebeck]

On Sonntag, 25. Juli 2021 14:48:11 CEST Hans Åberg wrote:
> Indeed, there is an example in the Bison manual, sec. 1.5.2, on how to use
> GLR resolve C++ style ambiguities. C++ is not LALR, so if using that, one
> has to write a grammar for a larger language and cut it down in the
> actions.
> > On 25 Jul 2021, at 09:45, Alex Shkotin  wrote:
> > 
> > or try %glr-parser command - it helps in my case:-)
> > 
> > сб, 24 июл. 2021 г. в 21:16, Hans Åberg :
> > > On 24 Jul 2021, at 16:34, Guenther Sohler 
> > > wrote:
> > > 
> > > When trying to code a c language parser I got a issue with shift/reduce
> > > conflict in bison, which actually hurts me.
> > 
> > You might check the LALR(1) grammars for C and C++ others have done. Two
> > examples:
> > https://isocpp.org/wiki/faq/compiler-dependencies#yaccable-grammar
> > http://www.quut.com/c/ANSI-C-grammar-y.html

Actually in Guenther's particular case his grammar definition is simply wrong, 
i.e. there is no need for grabbing the GLR hammer just for that.

On Samstag, 24. Juli 2021 16:34:15 CEST Guenther Sohler wrote:
> my rules are like this:
> 
> functiondefinition:
> type_ptr identifier '(' vardeclarationlist ')' compound_statement ;

That would assume the following code would be valid C:

int myFunction(int a, b /*wrong*/, c /*wrong*/) {
}

Which is not. You have to separate in the grammar definition between variable 
declaration inside a scope/block, example:

void foo() {
int a, b, c; // allowed here
}

and declaration of function arguments. E.g. change your grammar definition to 
something like (not tested):

functiondefinition:
type_ptr identifier '(' arglist ')' compound_statement ;

arglist :
arg |
arglist | arg;

arg :
type_ptr identifier;

> vardeclarationlist :
> vardeclaration |
> vardeclarationlist ',' vardeclaration  ;
> example: int a, int b=2
> 
> vardeclaration:
> type_ptr identifierlist  ;
> example: int *b
> 
> identifierlist :
> identifierwithdefault |
> identifierlist ',' identifierwithdefault
> 
> identifierwithdefault:
> identifier |
> identifier '=' expression |
> identifier '[' INTNUM ']'
> 
> 
> type_ptr :
> type_ptr '*' |
> type ;
> example: int

Best regards,
Christian Schoenebeck

Re: text is not parsed correctly due to shift/reduce conflict

[Hans Åberg]

Indeed, there is an example in the Bison manual, sec. 1.5.2, on how to use GLR 
resolve C++ style ambiguities. C++ is not LALR, so if using that, one has to 
write a grammar for a larger language and cut it down in the actions.


> On 25 Jul 2021, at 09:45, Alex Shkotin  wrote:
> 
> or try %glr-parser command - it helps in my case:-)
> 
> сб, 24 июл. 2021 г. в 21:16, Hans Åberg :
> 
> > On 24 Jul 2021, at 16:34, Guenther Sohler  wrote:
> > 
> > When trying to code a c language parser I got a issue with shift/reduce
> > conflict in bison, which actually hurts me.
> 
> You might check the LALR(1) grammars for C and C++ others have done. Two 
> examples:
> https://isocpp.org/wiki/faq/compiler-dependencies#yaccable-grammar
> http://www.quut.com/c/ANSI-C-grammar-y.html
> 
> 
> 

Re: text is not parsed correctly due to shift/reduce conflict

[Hans Åberg]

> On 24 Jul 2021, at 16:34, Guenther Sohler  wrote:
> 
> When trying to code a c language parser I got a issue with shift/reduce
> conflict in bison, which actually hurts me.

You might check the LALR(1) grammars for C and C++ others have done. Two 
examples:
https://isocpp.org/wiki/faq/compiler-dependencies#yaccable-grammar
http://www.quut.com/c/ANSI-C-grammar-y.html

text is not parsed correctly due to shift/reduce conflict

[Guenther Sohler]

Hi Folks,

When trying to code a c language parser I got a issue with shift/reduce
conflict in bison, which actually hurts me.

It happens when parsing this:

int main( int a,[XXX] int b)

[XXX] is the pointer of the issue:
When reading the comma it does not know wether to continue iterating in
vardeclarationlist or in identifierlist.
If the software looked one token ahead to see if after the ',' there is a
type it should proceed iterating the vardeclarationlist, else proceed with
the identifierlist.
How can i improve my situation ?

best regards Günther

Rules below



my rules are like this:

functiondefinition:
type_ptr identifier '(' vardeclarationlist ')' compound_statement ;

vardeclarationlist :
vardeclaration |
vardeclarationlist ',' vardeclaration  ;
example: int a, int b=2

vardeclaration:
type_ptr identifierlist  ;
example: int *b

identifierlist :
identifierwithdefault |
identifierlist ',' identifierwithdefault

identifierwithdefault:
identifier |
identifier '=' expression |
identifier '[' INTNUM ']'


type_ptr :
type_ptr '*' |
type ;
example: int