Re: Bison parser exhibiting weird behavior

Thank you for your response.

I have added assertions directly at the bison level as you suggested, 
and as follows :

block_list:
     block_expr '\n'
     {$$ = new_expression(exprBlock, 1, $1);
      assert($$->type == exprBlock);
     }
   | block_list block_expr '\n'
     {fprintf(stderr, "$1 : %lx\n$2 : %lx\n", (size_t)$1, (size_t)$2);
      assert($1->type == exprBlock);
      assert($1 != $2);
      expression_add_child($1, $2);
      $$ = $1;
     }
   ;

However, the output is the following :

Reducing stack by rule 17 (line 118):
    $1 = nterm block_list ()
    $2 = nterm block_expr ()
    $3 = token '\n' ()
$1 : 5617da9dd620
$2 : 5617da9dd620
flang: src/parser.y:120: yyparse: Assertion `(yyvsp[-2].expr)->type == 
exprBlock' failed.

With assert($1 != $2); failing as well if assert($1->type == exprBlock); 
is commented out.

>My guess would be that block_expr can be constructed by some other rule
>(possibly one that doesn't require \n) that produces an exprVar, and
>then the list is constructed.  Or new_expression() is not doing what's
>expected.

I assume you mean block_list ? There is no other rule that constructs one.

>I just don't think that's possible, if $1 and $2 are pointers.  If they
>are values and operator== is overloaded, that's another story.

They are in fact pointers, and there is no overload since this is plain C. That is why it perplexes me so much.
Meanwhile, i have read through the Bison parser and nothing looks wrong on sight. I also have tried allocating an extra 256 bytes to my expression structs in case it was an underallocation (with free arrays in structs or however they are called), but the errors still pop up.