Hi Alexandre, On Mon, 18 May 2009, Alexandre Bique wrote:
> Anything new ? Did you applied or read the patch ? Thanks for the patch. The basic idea looks fine to me, but there are some issues. > --- /usr/share/bison/glr.c 2008-12-12 09:29:32.000000000 +0000 > +++ glr.c 2009-04-04 01:07:36.000000000 +0100 > @@ -2631,6 +2631,7 @@ > #endif > ] > > +m4_define(b4_header_prefix,m4_translit(b4_prefix, `[a-z:]', `[A-Z_]')) The expansion of b4_prefix is underquoted. For example, if the prefix contains a comma, M4 gives a cryptic error message to the user. Of course, it's not a valid prefix in that case, but we should let the C compiler give an intelligible error message instead. > b4_epilogue > dnl > dnl glr.cc produces its own header. > @@ -2641,6 +2642,8 @@ > b4_copyright([Skeleton interface for Bison GLR parsers in C], > [2002, 2003, 2004, 2005, 2006]) > > +#ifndef b4_header_prefix[]_PARSER_HEADER_H > +# define b4_header_prefix[]_PARSER_HEADER_H To me, _HEADER seems redundant given the _H. > b4_shared_declarations > > b4_pure_if([], > @@ -2650,4 +2653,5 @@ > [extern YYLTYPE ]b4_prefix[lloc;]) > ]) > ])]) > +#endif /* !b4_header_prefix[]_PARSER_HEADER_H */ > m4_divert_pop(0) The #endif is misplaced. When no header file is requested, the code will not compile. Ultimately, something like this needs to be applied to the other C/C++ skeletons as well. Akim, is this approach compatible with your plans for the C++ skeletons? Can anyone think of any C/C++ use cases that the header guards would break? That is, should they be disabled by default? Is there any reason to disable them for --yacc?
