Bison extra $$ assignment problem

[Hans Aberg]

I have found a problem with an extra assignment the parser that Bison
generates, which could cause a C++ program to fail. The section in
bison.simple is the following:

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:
     `{dollar}{dollar} = {dollar}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];

It is this extra assignment $$ = $1 that may cause problems under C++:

I used
#define YYSTYPE my_type
class my_type {
public:
...
  std::string text;
  std::auto_ptr<std::string> condition;
...
};

and a semantic action
     { $$.condition = std::auto_ptr<std::string>(new std::string($1.text)); }
and later, in another rule, the seemingly harmless action
(*)  { $$.condition = $1.condition; }

The problem is no this that auto_ptr own a pointer with is transferred to
another auto_ptr via assignment, and then sets its own pointer to 0. So
when Bison throws in the extra $$ = $1, the pointer that $1.condition owns
is transferred to $$.condition, and in the later semantic action (*), the
now 0 pointer of $1.condition is transferred to $$:

The result is that, instead of transferring a pointer from $1.condition to
$$.condition, it is deleted!

Under C this cannot happen because one is not allowed to write ones own
operator=.

But this means that if Bison should have official C++ support in the
future, this extra assignment cannot be there (or one should at least be
able to ensure it is not there by some Bison option).



  Hans Aberg