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, 5 Oct 2012 10:32:22 +0200

Hi Paul,

Le 4 oct. 2012 à 02:55, Paul Eggert a écrit :

> In the meantime, here is a similar grammar that
> does not run afoul of the GCC bug, i.e., GCC correctly
> reports that yylval is uninitialized:
> 
> %pure-parser
> %code
> {
>  #define YYSTYPE double
>  extern void report_error (const char *);
>  extern void handle_value (int);
>  static void yyerror (const char *msg)
>  {
>    report_error (msg);
>  }
> 
>  static int yylex (YYSTYPE *lvalp)
>  {
>    static const char *input = "a";
>    return *input++;
>  }
> 
>  int main (void)
>  {
>    return yyparse ();
>  }
> }
> 
> %token 'a';
> %%
> exp: 'a' { handle_value ($1); };

But in that case chances are high that GCC will be a pain
in the neck in a more realistic version of this grammar:

  %pure-parser
  %code
  {
  # include <stdio.h>
  # include <stdlib.h>
  
  #define YYSTYPE int
  
   void yyerror (const char *msg)
   {
     fprintf (stderr, "%s\n", msg);
   }
  
   int yylex (YYSTYPE *lvalp)
   {
     static const char *input = "((0))";
     int res = *input++;
     if (res == '0')
       *lvalp = 42;
     return res;
   }
  
   int main (void)
   {
     return yyparse ();
   }
  }
  
  %%
  start: exp { printf ("%d\n", $1); };
  exp: '(' exp ')'  { $$ = $2; }
     | '0'          { $$ = $1; }
  ;

It's the same grammar, but I make it do something:
not all the tokens will have a value, and I suspect
there are very few grammars for which it is guaranteed
that the first token will have a value.

Yet, funnily enough, GCC does not complain here (with
your patch).  Nor does it with

   int yylex (YYSTYPE *lvalp)
   {
     static const char *input = "((0))";
     int res = *input++;
     if (res == 'x') // semantic value is never initialized.
       *lvalp = 42;
     return res;
   }

which obviously will never set properly lval when we need
it.



In my opinion the costs of this patch (added complexity
with a tricky form of code duplication, entropy between
skeletons) outweigh by far (if "far" applies to weights :)
its benefits.




reply via email to

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