Hi Peng,
> Le 11 févr. 2019 à 18:12, Peng Yu <pengyu...@gmail.com> a écrit :
>
> Hi,
>
> yacc_EOF instead of 0 is used in `yylex()`.
>
> http://git.savannah.gnu.org/cgit/bash.git/tree/parse.y#n3257
Which is
if (character == EOF)
{
EOF_Reached = 1;
return (yacc_EOF);
}
> The grammar explicitly relies on yacc_EOF.
>
> http://git.savannah.gnu.org/cgit/bash.git/tree/parse.y#n376
Which is:
%left '&' ';' '\n' yacc_EOF
%left AND_AND OR_OR
%right '|' BAR_AND
> But this seems to be different from the normal usage in flex/bison.
> For example, flex has <<EOF>> (I know bash doesn't use its hand coded
> yylex()). Bison expects yylex() to just return 0 upon seeing the EOF
> of the input.
Yes, it's very different indeed: here yacc_EOF is not declared
as being EOF.
> """ (From bison manual regarding yylex)
> The null character must not be used this way, because its code is zero
> and that signifies end-of-input.
> """
>
> So is there a reason bash parsing must the non-standard yacc_EOF? Or
> bash parsing can be solved by using a yylex() that returns 0 upon
> seeing EOF? Thanks.
I have no idea. You'd have to study the grammar to see if there
are doing fancy things around yacc_EOF. You could also map
declare yacc_EOF to be end-of-file to Bison, and see if things
work properly. Insert this:
%token yacc_EOF 0
It associates yacc_EOF with the token number 0, which denotes
EOF. However, I confess I never tried to use the symbol EOF
in grammar rules. It's a very special token, you cannot do
anything with it.
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
