Re: C99 in Bison

[Joel E. Denny]

Hi Akim.

On Wed, 26 Aug 2009, Akim Demaille wrote:

> I have no opinion about this.  What are the others doing?  Say coreutils for
> instance :)

I just found this in the coreutils README:

  ***********************
  Pre-C99 build failure
  -----------------------
 
  There is a new, implicit build requirement:
  To build the coreutils from source, you should have a C99-conforming
  compiler, due to the use of declarations after non-declaration statements
  in several files in src/.  There is code in configure to find and, if
  possible, enable an appropriate compiler.  However, if configure doesn't
  find a C99 compiler, it continues nonetheless, and your build will fail.
  If that happens, simply[*] apply the included patch using the following
  command, and then run make again:
 
    cd src && patch < c99-to-c89.diff
 
  [*] however, as of coreutils-7.1, the "c99-to-c89.diff" file is no longer
  maintained, so even if the patches still apply, the result will be an
  incomplete conversion.  It's been 10 years.  Get a decent compiler! ;-)

> > If this is ok, we should probably add a configure.ac check for C99.

Currently, bison and coreutils use AC_PROG_CC_STDC, which currently tries 
to find a C99 compiler but will accept C89.  I think that makes most of 
the quote from coreutil's README true for bison.  Maybe we should just put 
something like that in bison's README in branch-2.5 and master.

> > And what about C99 for building Bison-generated parsers?
> 
> I doubt we can do that.  For a start we could move to C90 in yacc.c :)
>
> > #ifdef YYPARSE_PARAM
> > #if (defined __STDC__ || defined __C99__FUNC__ \
> >     || defined __cplusplus || defined _MSC_VER)
> > int
> > yyparse (void *YYPARSE_PARAM)
> > #else
> > int
> > yyparse (YYPARSE_PARAM)
> >    void *YYPARSE_PARAM;
> > #endif
> > #else /* ! YYPARSE_PARAM */
> > #if (defined __STDC__ || defined __C99__FUNC__ \
> >     || defined __cplusplus || defined _MSC_VER)
> > int
> > yyparse (void)
> > #else
> > int
> > yyparse ()
> > 
> > #endif
> > #endif

It would be nice to see that cleaned up.  Of course, yacc.c uses some M4 
macros to hide this away for us, but even that could be easier to read.

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

> All the other functions are KnR compliant too.  Maybe we should poll the
> audience, say via NEWS.

What about the following?  It should probably remain at the very top of 
2.4.2 news.

diff --git a/NEWS b/NEWS
index 57db6c2..4e29918 100644
--- a/NEWS
+++ b/NEWS
@@ -122,6 +122,18 @@ Bison News
 
 * Changes in version 2.4.2 (????-??-??):
 
+** User Poll: Bison to drop K&R C support.
+
+  Bison has always generated LALR(1) parsers that can be compiled using
+  a K&R C compiler.  However, K&R C is over 30 years old.  The Bison
+  developers are ready to take a step forward.  For release 2.5, we are
+  considering requiring a C89/C90 compiler.  If you feel this is an
+  unreasonable change that would adversely affect Bison's user base,
+  please write us at <address@hidden>.
+
+  To be clear, building the `bison' executable itself already requires a
+  C89/C90 compiler.  Building release 2.5 will require a C99 compiler.
+
 ** Detection of GNU M4 1.4.6 or newer during configure is improved.
 
 ** %code is now a permanent feature.