Re: C99 in Bison

[Akim Demaille]

> > If I read correctly our parse-gram.c, we have two errors:
> >
> > > # ifndef yytnamerr
> > > /* Copy to YYRES the contents of YYSTR after stripping away  
> > > unnecessary
> > >  quotes and backslashes, so that it's suitable for yyerror.  The
> > >  heuristic is that double-quoting is unnecessary unless the string
> > >  contains an apostrophe, a comma, or backslash (other than
> > >  backslash-backslash).  YYSTR is taken from yytname.  If YYRES is
> > >  null, do not copy; instead, return the length of what the result
> > >  would have been.  */
> > > static YYSIZE_T
> > > yytnamerr (char *yyres, const char *yystr)
> > > {
> >
> >
> > and
> >
> > > static YYSIZE_T
> > > yysyntax_error (char *yyresult, int yystate, int yytoken)
> > > {
>
> Have we seen any complaints from the users about this?  Then again, I
> suppose not every user enables this code.

My quotation does not make it clear, but yysyntax_error is always  
defined (and used, even for "simple" messages), and always with this  
signature.  So that one is really wrong.

It goes back to

commit b4c1f9d2b647df6b70732d76bbf5bc9b21372e9a
Author: Paul Eggert <address@hidden>
Date:   Tue Sep 20 06:06:42 2005 +0000

which is quite old :)  A grep in NEWS gives:

* Changes in version 2.1, 2005-09-16:

so I guess we can afford dropping knr in the generated skeletons,  
without polling in the NEWS (but we can inform in the NEWS of 2.4.2  
that 2.5 will completely drop KnR support in yacc.c, which was  
accidentally broken anyway since Bison 2.1).  After all, old tarballs  
are still there.

As for C90 in bison itself, I'm fine with it.  Yet C++03 would be  
better ;)