On Mon, Oct 31, 2011 at 11:19:27PM +0400, Ilya Barygin wrote:
> The code in question is:
>
> static void yyFail (yyGLRStack* yystackp, const char* yymsg)
> __attribute__ ((__noreturn__));
> static void
> yyFail (yyGLRStack* yystackp, const char* yymsg)
> {
> if (yymsg != NULL)
> yyerror (yymsg); // this gives a warning
> YYLONGJMP (yystackp->yyexception_buffer, 1);
> }
>
> Looks like problem is in bison.
Hello Ilya and Michael,
I am sorry but it does not: yyerror is provided by nip2 and must follow bison
calling interface. If yyerror causes an error, then this is a bug in nip2.
nip2 is providing a function yyerror which is variadic:
void yyerror( const char *sub, ... )
__attribute__((format(printf, 1, 2)));
the bison documentation states that the expected prototypes is
void yyerror (char const *msg); /* Yacc parsers. */
and furthermore:
The prototypes are only indications of how the code produced by Bison
uses `yyerror'. Bison-generated code always ignores the returned
value, so `yyerror' can return any type, including `void'. Also,
`yyerror' can be a variadic function; that is why the message is always
passed last.
So while it is valid for yyerror to be variadic, it is not valid for yyerror
to have the attribute __attribute__((format(printf, 1, 2))) because this
violates
the bison calling convention for yyerror.
nip2 should have two functions, a variadic nip2error and a 1-arg yyerror
reserved for
bison use. yyerror can be a wrapper around nip2:
void yyerror(const char *s) { nip2error("%s",s); }
The proposed patch is misguided and will breaks any software that use bison
properly.
Cheers,
--
Bill. <ballo...@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
