[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bison-1.875: yyerror() declaration and C++ compilation error

From: Paul Eggert
Subject: Re: bison-1.875: yyerror() declaration and C++ compilation error
Date: Thu, 2 Jan 2003 22:23:16 -0800 (PST)

> Date: Thu, 2 Jan 2003 19:10:03 -0700 (MST)
> From: "Nelson H. F. Beebe" <address@hidden>
> A check of the bison manual shows that yyerror() is now expected to be
> declared by the user:

That change was merely to the documentation.  The code didn't change.
As far as I know, Bison has never generated a declaration for yyerror.
This was not documented clearly until recently, since it wasn't much
of an issue for K&R C or for C89, which do not require functions to be
declared.  However, it is an issue for C99 and for C++.

Is your program portable to Berkeley yacc?  If so, then I'm puzzled,
since byacc doesn't declare yyerror either.

Which yacc were you using (i.e., which yacc generated a parser that
declared yyerror)?

I gather that your yacc used something along the lines of Solaris 9
yacc, since you mentioned YYCONST in your email.  Did your yacc also
declare yylex and yyparse?  (Solaris 9 yacc does, usingly
quite-complicated rules.)  Does your code rely on these declarations?

Solaris 9 yacc declares yyerror, using some fairly complicated code
that boils down to this:

        #ifdef __STDC__
        # define YYCONST const
        # define YYCONST

        #if defined __cplusplus && ! defined yyerror
        # ifdef __EXTERN_C__
           extern "C" {
            void yyerror (YYCONST char *);
        # else
           void yyerror (YYCONST char *);
        # endif

Bison avoids this jumble by making the declaration of yyerror the
user's responsibility.  Why does YYCONST depend on __STDC__ and not
__cplusplus?  What is the role of __EXTERN_C__?  Why is yyerror
declared for __cplusplus and not for __STDC__?  It all seems a bit
strange to me.

> I don't see why that should be necessary since bison itself
> generates calls to it, and thus should provide a suitable prototype.

One cannot deduce a prototype from the calls.  For example, some
people prefer yyerror to take char *, while others prefer char const
*.  Some people prefer yyerror to return int, while others prefer it
to return void.  All of these choices work with the code that Bison
generates, but they could well lead to incompatible prototypes if
Bison declared yyerror itself.  That is why it has always been the
user's responsibility to declare yyerror.

> An additional check in the installed yacc.c file is needed:
>       #if defined (__GNUC_MINOR__) && 2093 <= (__GNUC__ * 1000 + 
> __GNUC_MINOR__) && !define(__GNUG__)
> but perhaps there is a cleaner way.

Won't it suffice to append a semicolon to the __attribute__ line, as
in the patch I sent you earlier today?

> Incidentally, I view it a very bad idea to install bison under the
> name yacc as well: that masks access to the native yacc when that may
> be what the user intended.

That was for POSIX conformance, which is becoming more of an issue
these days.

How about if we add a --disable-yacc option to "configure"?  It could
disable the installation of the "yacc" command, and it could also
disable the (relatively useless) -ly library that is required by

PS.  Thanks for your comments; they are helping to improve Bison's
portability and usefulness.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]