Re: bison valgrind

[Akim Demaille]

>>> "Paul" == Paul Hilfinger <address@hidden> writes:

 > This is actually Akim's code rather than mine, so I'm a tad uncertain as
 > to the "correct" fix.  The problem, at least, is clear: when entering
 > the error-recovery code as a result of YYERROR, yyerror_range[1] is 
 > uninitialized.  I request a second set of eyes take a look at the
 > suggested patch below, inspired by yacc.c, and tell me what you think.

I think I would have done the same.  I was in the process of reviewing
all the place the error location was updated, but I fail to remember
whether I had already covered YYERROR already or not.  The following
seems to prove I did not, in which case it also means that the test
suite is not covering this (ISTR that this was also a job for
calc.at).  That's a TODO.

 > I'll install it if I get feedback within the next day; otherwise, it
 > will have to wait until I return in a week.

 > Paul Hilfinger


 > Index: bison-1_5.103/data/glr.c
 > --- bison-1_5.103/data/glr.c Fri, 08 Jul 2005 14:48:04 -0700 hilfingr 
 > (glrbison/e/14_glr-parser 1.27.1.33.1.5.1.13 644)
 > +++ bison-1_5.103(w)/data/glr.c Fri, 08 Jul 2005 19:39:18 -0700 hilfingr 
 > (glrbison/e/14_glr-parser 1.27.1.33.1.5.1.13 644)
 > @@ -781,7 +781,8 @@ yyuserAction (yyRuleNum yyn, int yyrhsle
 >    else
 >      *yyvalp = yyvsp[YYFILL (1-yyrhslen)].yystate.yysemantics.yysval;
 >    YYLLOC_DEFAULT (*yylocp, yyvsp - yyrhslen, yyrhslen);
 > -]
 > +]b4_location_if([[  yystack->yyerror_range[1].yystate.yyloc = *yylocp;
 > +]])
 >    switch (yyn)
 >      {
 >        b4_actions