bug-bison
[Top][All Lists]
Advanced

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

Re: [PATCH] Fix variadic declaration of yyerror() and yylex() function p


From: Paul Eggert
Subject: Re: [PATCH] Fix variadic declaration of yyerror() and yylex() function prototypes
Date: Wed, 25 May 2005 00:45:45 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)

Jeannot Langlois <address@hidden> writes:

> 1- Can you have a look at my attached patch and tell me what you think
> of it?

It looks pretty good (comments below).  Thanks for taking
the time to attack this annoyance.

> It has been generated from released Bison-2.0 tree
> though... is that okay?

It'd be a bit easier for me if you did it against CVS Bison
<https://savannah.gnu.org/projects/bison>.  CVS is a bit of a hassle
since it requires bleeding-edge development tools, but Bison 2.0a
<ftp://alpha.gnu.org/gnu/bison/bison-2.0a.tar.gz> should be easy.

> 2- Would there be a better way to check for the return type of a
> user-declared yyerror() prototype that could exist, before my M4
> macros generate a potentially-conflicting yyerror() declaration?

How about if we have Bison use "int" when it is running in Yacc mode
(as POSIX requires), but "void" otherwise?  You can communicate this
information to the template, and let the template do its thing.

> 3- Why would "int" be used as the return type of user-declared
> yyerror() in testcases #117 to #126?  Doesn't Bison recommend to use
> "void" as the return type?

It's probably historical accident.  Do any of the examples link with
-ly?  If not, you can change them to "void".

> 4- I would appreciate any other comments regarding my current
> "tentative" patch, and will hope it might interest you enough to be
> considered for inclusion in the next release.... :-)

My main comment is a question: would you be willing to assign the
copyright to the Free Software Foundation, so that we could install it
in Bison?

Thanks again.




reply via email to

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