$$ = $1

[Akim Demaille]

Paul, the following comment and code do not agree:


   /*-----------------------------.
   | yyreduce -- Do a reduction.  |
   `-----------------------------*/
   yyreduce:
     /* yyn is the number of a rule to reduce with.  */
     yylen = yyr2[yyn];
   
     /* If YYLEN is nonzero, implement the default value of the action:
        `$$ = $1'.
   
        Otherwise, the following line sets YYVAL to the semantic value of
        the lookahead token.  This behavior is undocumented and Bison
        users should not rely upon it.  Assigning to YYVAL
        unconditionally makes the parser a bit smaller, and it avoids a
        GCC warning that YYVAL may be used uninitialized.  */
     yyval = yyvsp[1-yylen];


The comment refers to rules without any lhs, i.e., yylen = 0, i.e., we
point to yyvsp[1], in other words one past the end of the stack: a
no-bit-land.

I face the same problem for the default location, which when there is
a non empty lhs, amounts to

        @$ = range from @1 to @n

when the lhs is empty, I'm not sure what I should do.  And the problem
is worse in that case, since it is *always* legal to ask for the
location of some symbol.  What does make sense in that case, is to
have a 0-width location starting where the last symbol ended (@0), and
ends at the same point.  It is so dependent on the way locations are
built that I see no other means that providing the user with a means
to access the location of that previous symbol.  An example might make
it clearer:

        exp: one empty one;
        one: '1';
        empty: ;

on the input `11', one should have in the first rule

        exp: one empty one { @1 = 0-1; @2 = 1-1; @3 = 1-2; }

when m-n means from column m to column n.  So when reducing empty, it
should be given @0, the location of the first one :(



Anyway, back to our $$ = $1.  I fail to see what real problem the code
could introduce.  Sure, we read unitialized bytes, but tools such as
Valgrind are fine with this *except* if you *use* this value.  But
then, the user is wrong anyway, since she didn't specify a value for
`empty'.  The other problem might be looking past the actually
allocated stack, but I couldn't make a test case that exhibits this
failure (I'll try again tomorrow, I must go now, but maybe the limits
we have on the stack always ensures we can use its top + 1.  I haven't
enough time to check now).

What fix would you suggest?