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...

Reply via email to