[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug in Bison-2.1 (and previous)?
From: |
Steve Murphy |
Subject: |
Bug in Bison-2.1 (and previous)? |
Date: |
Thu, 13 Apr 2006 09:04:14 -0600 |
Hello!
In my bison input file, I have the following options defined:
/* OPTIONS */
%locations
%pure-parser
%name-prefix="ael_yy"
/* the following option does two things:
it adds the locp arg to the yyerror
and it adds the NULL to the yyerrr arg list, and calls
yyerror with NULL for that arg.
You can't get the locp arg without the NULL arg, don't ask
me why. */
%parse-param {void *NULL}
/* there will be two shift/reduce conflicts, they involve the if
statement, where a single statement occurs not wrapped in
curlies in the "true" section
the default action to shift will attach the else to the
preceeding if. */
%expect 5
%error-verbose
The above will cause the yyerror calls to appear as:
yyerror (&yylloc, NULL, "syntax error: cannot back up");\
and I (out of necessity) defined yyerror as :
void yyerror(YYLTYPE *locp,void *nothing, char const *s);
Trouble is, that I need this to be a pure parser, and I need yyerror to
bump a count of the number of syntax errors. So I desparately need that
middle argument to pass in a pointer to a struct (or whatever), so I
increment the error count. I can't do it as a global!
So, I tried playing with %parse-param, but it seems to be a boolean; if
it's set, I get three args to yyerror; but it doesn't matter what it's
set to. If I change it, I get the same results. Its value isn't used.
Perhaps I'm missing something. How do I set what the middle variable of
the yyerror call will be? Instead of NULL, I'd sure like to it to be:
yyerror (&yylloc, struct_ptr_var, "syntax error: cannot back up");
or whatever...
In my mind, specifying '%locations' should be sufficient to add the
&yylloc arg to the yyerror call (along with whatever else it does), and
the %pure-parser should alone add the struct_ptr_var to the call. And
it'd be nice if I specified,
%parse-param my_ptr_struct
that this would define what the middle arg to yyerror would be...
in general, though, you might consider that if %pure-parser is
specified, EVERY user-definable function called from within the parse
function should have that var used as an arg. Let's see, what other
user-definable functions are there besides yyerror? How about, yyparse?
But yyparse is a function declaration, and yyerror is a call... so I
guess I'm asking for TWO options, one for each:
%parse-param (struct something *my_struct_ptr)
%pure-parse-arg my_struct_ptr
unless bison is intelligent enough to extract the "my_struct_ptr" from
the parse-param value...
Another matter--
I had to redefine/predefine several macros, so as to quiet compiler
complaints, and get things to work:
(the following is in the first %{ section at the top of the .y file):
#define YYPARSE_PARAM parseio
#define YYLEX_PARAM ((struct parse_io *)parseio)->scanner
#define YYERROR_VERBOSE 1
/* this stuff is included so I can declare the proto for yyerror
*/
#if ! defined (YYLTYPE) && ! defined (YYLTYPE_IS_DECLARED)
typedef struct YYLTYPE
{
int first_line;
int first_column;
int last_line;
int last_column;
} YYLTYPE;
# define yyltype YYLTYPE /* obsolescent; will be withdrawn */
# define YYLTYPE_IS_DECLARED 1
# define YYLTYPE_IS_TRIVIAL 1
#endif
#if ! defined (YYSTYPE) && ! defined (YYSTYPE_IS_DECLARED)
typedef union YYSTYPE {
char *str;
struct pval *pval;
} YYSTYPE;
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
# define YYSTYPE_IS_TRIVIAL 1
#endif
void yyerror(YYLTYPE *locp,void *nothing, char const *s);
int ael_yylex (YYSTYPE * yylval_param, YYLTYPE * yylloc_param ,
void *yyscanner);
It seems that YYLTYPE and YYSTYPE are not defined at point where the
%{ stuff is included; so I had to insert these definitions myself; Seems
to me that if user defined function prototypes are to be declared in
these, that the structs & etc that they would naturally use, should be
defined before these are possibly used!
Either I'm doing things wrong, or the above code is pointing out
problems with bison... which is it?
murf
- Bug in Bison-2.1 (and previous)?,
Steve Murphy <=