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
