Re: strange K&R expansion of yyparse()

[Tim Van Holder]

Anthony Heading wrote:
> Hi,
> 
> I've just started to trip over a problem where a parser is not compiling
> using MSVC 2005.  I'm not sure why I just started encountering this now -
> maybe cygwin has only just upgraded to bison 2.1?  Anyhow, for any parser
> at all, the bison=2.1 / m4=1.4.4  yacc.c skeleton code looks like this:
> 
> 
>       /*----------.
>       | yyparse.  |
>       `----------*/
> 
>       #ifdef YYPARSE_PARAM
>       # if defined (__STDC__) || defined (__cplusplus)
>       int yyparse (void *YYPARSE_PARAM)
>       # else
>       int yyparse (YYPARSE_PARAM)
>       void *YYPARSE_PARAM;
>       # endif
>       #else /* ! YYPARSE_PARAM */
>       #if defined (__STDC__) || defined (__cplusplus)
>       int
>       yyparse (void)
>       #else
>       int
>       yyparse ()
>           ;           <==========  should this semicolon be here?
>       #endif
>       #endif
>       {
> 
>       int yystate;
> 
> 
> It looks like there's a empty string being written out as K&R function
> argument.  Debugging by mixing and matching bits of bison 2.0 and bison 2.1,
> I see some m4sugar macros have changed pretty radically.  Copying the bison
> 2.0 m4sugar file into a 2.1 tree gets rid of this semicolon.
> 
> (As a sidenote, I was a bit surprised to see that this was falling through
> a K&R code path using Microsoft's latest compiler!  Googling a bit
> suggests that __STDC__ is only turned on when MS extensions are disabled,
> which is a reasonable strict interpretation of the purpose of the symbol,
> I suppose.  Given it's 2006, should K&R support maybe not be relegated to
> a special YY_ANCIENT_KR_COMPILER type of symbol?)
> 
> Pls let me know if this problem is as replicable as it seems - happy to
> investigate some more if the problem is more complex than I thought...

I have seen the same thing, I just hadn't gotten around to reporting it
yet.  The problem seems to be either in b4_c_knr_formal_decls (in c.m4)
or its callers.  It calls m4_map_sep to invoke b4_c_knr_formal_decl on
its arguments, and the latter will happily emit '      ;'.  Normally
this shouldn't happen, because m4_map_sep will not do anything if passed
nothing (and there are no parse parameters so that should be the case).
However, b4_c_knr_formal_decls gets called with '[]' as argument. It
smelled like overquoting somewhere along the line but I didn't want to
find out where so I just went with a workaround:

m4_define([b4_c_knr_formal_decls],
[m4_if(address@hidden, [[]], [],
       [
m4_map_sep([b4_c_knr_formal_decl],
           [
],
           address@hidden)])])

(with a dnl added after the b4_c_knr_formal_names invocation in
b4_c_function_def, to avoid the empty line if there are no parameters).