Re: better error reporting with bison and flex

2006-06-27 Thread Guillaume Rousse
Tim Van Holder wrote: > Guillaume Rousse wrote: >> Which is really not meaningful for user :/ I'd prefer to at least >> display current line, and avoid refering to internal grammar symbols. > > Part 2 - not referring to internal grammar symbols: use string aliases > for your tokens, like so: > >

Re: better error reporting with bison and flex

2006-06-22 Thread Tim Van Holder
Guillaume Rousse wrote: > Which is really not meaningful for user :/ I'd prefer to at least > display current line, and avoid refering to internal grammar symbols. Part 2 - not referring to internal grammar symbols: use string aliases for your tokens, like so: %token MY_IDENTIFIER "identifier" %

Re: better error reporting with bison and flex

2006-06-22 Thread Guillaume Rousse
Satya wrote: > hi, > As I understand, you want to refer to the user's exact input symbol in > the error message rather than the grammar symbol associated with it.. > ? Rather the whole input line than just an isolated part of it. > Well, flex provides a global variable 'yytext' that contains the v

Re: better error reporting with bison and flex

2006-06-22 Thread Satya
hi, As I understand, you want to refer to the user's exact input symbol in the error message rather than the grammar symbol associated with it.. ? Well, flex provides a global variable 'yytext' that contains the value of the symbol. Suppose you have a definition like this in your lexer: [0-9]+

better error reporting with bison and flex

2006-06-22 Thread Guillaume Rousse
Hello. I'm trying for two days now to produce better output messages in case of parsing failure. I'm using flex + bison for a standard (non-reentrant) parser. I've had to redefine YY_INPUT in scanner.l, as I'm parsing small, line-based messages, and default version was blocking: #define YY_INPUT