Thanks for the comments. Happy to take a stab at going the bc/bc.y route if that seems acceptable. That yyerror handler looks much more helpful.
On Mon, Jul 9, 2018 at 4:04 AM Otto Moerbeek <o...@drijf.net> wrote: > On Mon, Jul 09, 2018 at 01:52:29AM -0600, Theo de Raadt wrote: > > > Otto Moerbeek <o...@drijf.net> wrote: > > > > > On Mon, Jul 09, 2018 at 01:21:25AM -0600, Theo de Raadt wrote: > > > > > > > Phil Eaton <philneato...@gmail.com> wrote: > > > > > > > > > Hey, > > > > > > > > > > Doas currently tells you the line but not the column for syntax > errors. In > > > > > the case of a missing newline at the end of a line I was confused. > So I > > > > > added the column number to the message as well. > > > > > > > > > > Also, is there any interest in relaxing the grammar so a trailing > rule > > > > > without a newline is ok? > > > > > > > > > > Let me know what you think. > > > > > > > > > > diff --git parse.y parse.y > > > > > index fde406bcf5a..f98deb81706 100644 > > > > > --- parse.y > > > > > +++ parse.y > > > > > @@ -195,7 +195,7 @@ yyerror(const char *fmt, ...) > > > > > va_start(va, fmt); > > > > > vfprintf(stderr, fmt, va); > > > > > va_end(va); > > > > > - fprintf(stderr, " at line %d\n", yylval.lineno + 1); > > > > > + fprintf(stderr, " at line %d, column %d\n", yylval.lineno + 1, > > > > > yylval.colno); > > > > > parse_errors++; > > > > > } > > > > > > > > I don't see the point of this verboseness, and doubt our yacc and > lexer > > > > cooperate well enough to provide a correct colno. > > > > > > Agreed. I prefer to have the parser print the unexpected token. This > > > is on my to-do list, but give it a shot if you want. You can use > > > bc/bc.y as an exmaple of a possible approach. > > > > I still don't see the point. In 30 years, I've gotten by with parsers > > that say "syntax error", and had very bad experiences with programs > > that do a poor job anticipating where the parse error is. Of course > > there are programs which do a good job of detecting the error, but > > generally those don't use yacc... > > I'm not trying to guess anything. yacc uses one-token lookahead. If it > cannot continue, the lexical value of the token that could not be > processed gives a pretty clear indication of the error spot. > > -Otto > -- Phil Eaton
