[Top][All Lists]

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

Re: strange K&R expansion of yyparse()

From: Tim Van Holder
Subject: Re: strange K&R expansion of yyparse()
Date: Tue, 09 May 2006 08:42:26 +0200
User-agent: Thunderbird (Windows/20060308)

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_if(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).

reply via email to

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