25.05.2019 2:19, Adriano dos Santos Fernandes wrote:
Hi!
We always let btyacc nicely handle parser backtracking alone but seems
in some cases we should not let it.
CORE-6068 is such a case. Parser enters in near-infinite loop allocating
and freeing memory trying new paths.
Based on the short btyacc documentation, YYVALID should be used to fix
these cases.
Unfortunately, the readme is really short and only example of how to use
YYVALID I found at extern\btyacc\test\t2.y:
input: decl_list(global_scope = new_scope(0)) ;
decl_list($e): | decl_list decl($e) ;
decl($e):
decl_specs declarator_list($e,$1) ';' [YYVALID;]
| decl_specs declarator($e,$1) block_statement(start_fn_def($e, $2))
{ finish_fn_def($2, $3); }
;
I've put it here and the problem is gone:
-----
%type <stmtNode> proc_statement
proc_statement
: simple_proc_statement ';' [YYVALID;]
{ $$ = newNode<LineColumnNode>(YYPOSNARG(1).firstLine,
YYPOSNARG(1).firstColumn, $1); }
| complex_proc_statement [YYVALID;]
{ $$ = newNode<LineColumnNode>(YYPOSNARG(1).firstLine,
YYPOSNARG(1).firstColumn, $1); }
;
-----
Do you see any problem to stop backtracking on these places?
Usage of YYVALID seems as correct way to fix the problem, but... first explain
please - why do you mark both rules as valid and why it solves the issue ?
Note, in test\t2.y above just one rule is marked and it looks logical for me.
Probably i missed something. Could you point me ?
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
