Re: No header guard in glr.c skeleton (bison 2.4.1)

[Joel E. Denny]

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?