bison-patches
[Top][All Lists]
Advanced

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

Re: {maint} yacc.c: initialize yylval in pure-parser mode


From: Akim Demaille
Subject: Re: {maint} yacc.c: initialize yylval in pure-parser mode
Date: Fri, 28 Sep 2012 09:22:04 +0200

Hi Paul!

Le 27 sept. 2012 à 18:11, Paul Eggert a écrit :

> On 09/27/2012 08:38 AM, Akim Demaille wrote:
>> In fact, one of your initial goal was:
>> 
>>>> And in the unusual case where
>>>> where yylval really *isn't* initialized -- because the lexer is
>>>> buggy -- GCC will issue the warning, which will be a good thing.
> 
>> AFAICT, it is not the case, GCC does not complain in the following
>> attached test case where yylval is _not_ initialized.
> 
> If memory serves, GCC was correct to not complain in that test case,
> because the value of yylval was not used.

That's not true: the test case I sent _does_ use that
initial yylval, yet GCC does not complain.  Actually,
there was a bug (missing "static" for input), so here is
an updated version.

$ cat foo.y
%pure-parser
%union {int ival;}
%code
{
# include <stdio.h>
# include <stdlib.h>
  void yyerror (const char *msg)
  {
    fprintf (stderr, "%s\n", msg);
  }
  
  int yylex (YYSTYPE *lvalp)
  {
    static const char *input = "a";
    return *input++;
  }
  
  int main (void)
  {
    return yyparse ();
  }
}

%token <ival> 'a';
%%
exp: 'a' { printf ("%d\n", $1); };
$ ~/src/gnu/bison-2.5/_build/48-debug/tests/bison foo.y
$ grep read_token foo.tab.c
  goto yyread_token;
yyread_token:
$ gcc-mp-4.8 -Wall -O2 foo.tab.c
$ gcc-mp-4.8 -Wall foo.tab.c
$ gcc-mp-4.8 -Wall -O3 foo.tab.c
$ gcc-mp-4.8 -Wall -Wextra -O3 foo.tab.c
foo.y: In function 'yylex':
foo.y:12:23: warning: unused parameter 'lvalp' [-Wunused-parameter]
   int yylex (YYSTYPE *lvalp)
                       ^
$ ./a.out
0
$

> As I understand it, what we have is:
> 
> * The current situation, where GCC sometimes incorrectly
>   cries wolf.

Correct.

> * The simple patch you're proposing, which will cause
>   GCC to sometimes be silent even when there's a real wolf.

Yes.

> * The more-complicated patch I'm proposing, which will cause
>   GCC to be more accurate about wolf-reporting.

That's the goal, agreed, but GCC does not catch anything.
And FWIW, Clang neither.

$ clang-mp-3.2 -Wall -Wextra -O3 foo.tab.c
foo.y:12:23: warning: unused parameter 'lvalp' [-Wunused-parameter]
  int yylex (YYSTYPE *lvalp)
                      ^
1 warning generated.

> The code's pretty complicated already (it already has gotos
> into blocks, in other places),

OK, I missed that, thanks.

> and the extra complexity
> introduced by the more-complicated patch is not really
> all that much, which is why I proposed it.

I still think it is extra complexity because it unrolls
downstream code in a non-trivial way.  It
duplicates the logic, yet with added "optimizations" (or
simplifications).  So that's more coverage to check (be
sure that everything is right when the first token is
correct, an error, or eof), and makes us more sensitive
to change in the definition of the tables.

And the fact that the skeletons become too different
from one another is a real maintenance issue.




reply via email to

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