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

[Akim Demaille]

Hi Paul,

Thanks for having worked out something.

Le 19 sept. 2012 à 16:28, Paul Eggert a écrit :

> On 09/19/2012 06:05 AM, Akim Demaille wrote:
>> I have not seen answers to this message.
> 
> Sorry, I missed that one.  Thanks for the example;
> I think I see the problem now.  This appears to be
> a bug in GCC -- has someone filed a bug report?

No, I did not.  I tried to make the example as small as possible,
but it is still large.  Would you advice to report it anyway?

> Anyway, we can't expect users to get a fixed GCC, so it'd
> be nice to pacify the buggy one.  But
> instead of initializing yylval to zero, which
> is troublesome, how about if we initialize it
> to the value of the first input symbol?
> 
> That is, instead of this:
> 
>  yychar = YYEMPTY; /* Cause a token to be read.  */
> 
> How about if we do something like this:
> 
>  yychar = YYEMPTY;
> #ifdef __GNUC__
>  /* Avoid diagnostic "'yylval' may be used uninitialized in this              
>  
>     function".  Without this extra help, 'gcc -Wmaybe-uninitialized'          
>  
>     is not

> smart enough to see that yylval is always OK.  */
>  if (YYFINAL != 0 && !yypact_value_is_default (yypact[0]))
>    yychar = YYLEX;
> #endif

This does work (with 4.8).

> That way, GCC will be happy in the usual case.  It will optimize
> away most of the above gorp, and generate code that simply does
> "yychar = YYLEX".  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.

The idea is nice, but there are several issues.  One is that we
must be extremely careful with where to put this (cannot be what
you suggested, as the first call to yylex would be run before
%initial-action).  Another is that we have to
duplicate the messages from the traces ("Reading a token",
"next token is…").  I am also concerned with making the different
skeletons even more different.  And finally, I am not fond at all
of the idea of having different code paths for different compilers
(this is simply solved here by getting rid of the cpp guards).

There is already some work in master to make the control flow
somewhat simpler to understand, so there is hope that we might
reach a point where GCC would no longer complain.  But for
maint, I'd rather have something really simple.