3

I have an issue with the function definition in my C grammar wich can be found here http://www.archive-host.com/files/1959635/24fe084677d7655eb57ba66e1864081450017dd9/cAST.txt, it does not define correctly and I can't multiply it by something. The code I am tring to input is this one :

int factorielle(int n)
  { int x;
   if ( n == 0)
  return 1;
   else return n*factorielle(n-1);
  }

The function definition is this one :

function_definition
    : declaration_specifiers declarator compound_statement
    | declarator compound_statement
    ;

declaration_specifiers should be linked to int and declarator to factorielle(int n), to do this I replaced this :

direct_declarator
: ID ((direct_declarator '[' ']') | (direct_declarator '(' parameter_type_list ')') | (direct_declarator '(' identifier_list ')') | (direct_declarator '(' ')') )*

with

direct_declarator
: ID ((direct_declarator '[' ']') | (direct_declarator '(' parameter_type_list ')') | (direct_declarator '(' identifier_list ')') | (direct_declarator '(' ')')  | '(' parameter_type_list ')' )*

But it does not help much.

As for the multiplication I don't know how to do without bringing conflict. is there a way to fix this please ?

Exia0890
  • 441
  • 6
  • 21

2 Answers2

1

You're likely to have an difficult time parsing real C code using a pure grammar with pure ANTLR.

The reason is that certain declarations look like legitimate executable statements. (While the referenced answer seems to be about LR(1) parsers, it is really about parsers that cannot handle ambiguity; ANTLR cannot).

The only way to tell them apart is to use context information available from earlier symbol declarations. So you will have to collect symbol types as you parse, and inspect that information in the grammar rule reductions to decide whether such instances are statements or declarations. (I don't know how one implements this in ANTLR, although I believe it to be possible).

Community
  • 1
  • 1
Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • I see what you mean, as for the context I will see if I can learn it. But the input code are usually simple, the exemple I used should be one of the most complex that will be input in the grammar. But it is true I have many problem with the ambiguity. – Exia0890 Mar 09 '13 at 09:46
  • The difficulty with most programs (tools) is the "input is usually simple" but they in fact have to deal with the most complex case to be useful in practice. If you don't have iron-clad control of what people hand your tool, they will hand it the ugliest thing on the planet, and complain when it fails. If you are building a toy for educational purposes, you can ignore all the nasty complications, as long as you understand where you are cheating. – Ira Baxter Mar 09 '13 at 09:48
  • I see, seems like even simple statement can be difficult to manage. But I don't think I have knowledge with Antlr to have an "iron-clad control" on it, but I will try. – Exia0890 Mar 09 '13 at 10:32
  • It is certainly possible to parse real C code with ANTLR 3. I wrote an ANTLR 2 grammar which is on the antlr website. You can see how to deal with typedefs in it using semantic predicates, and how to deal with the declaration/function ambiguity using syntactic predicates. http://www.antlr3.org/grammar/cgram/ – monty0 Mar 11 '13 at 15:50
  • @monty0: Yes, I believe you can do it with ANTLR, but you have to have the context-checking hack. That's what I meant about "can't do it with a pure grammar". OP's problem is with *his* implementation, not *yours* :-{ – Ira Baxter Mar 11 '13 at 17:46
0

I may have found a solution to the first part of the issue by remplacing

compound_statement
  : '{' '}'
  | '{' statement_list '}'
  ;

with

compound_statement
  : '{' '}'
  | '{' statement_list '}'
  | '{' external_declaration+ '}'
  ;

and adding this to direct_declarator:

| ID '(' parameter_type_list ')'

But I don't know if it will bring some conflicts.

Exia0890
  • 441
  • 6
  • 21