Re: Bison parser exhibiting weird behavior

Solved it ! The reallocation of the expression in expression_add_child 
moved the block every time except when running in Valgrind (until a few 
minutes ago). That then caused the following expression, that was a 
parent of the previous one, to overwrite it except for the children 
list, thus causing a recursion.

Thank you everyone for the help !

PS : I am posting this here as "Nathanael" seems to have responded 
outside of the mailing list.

On 9/7/25 00:20, James K. Lowden wrote:
> On Sat, 6 Sep 2025 11:01:47 +0200
> Fr <[email protected]> wrote:
>
>> Upon inspection with GDB, it seems like when the assertion fails, $1
>> is of type exprVar (a possible expression type for a block_expr)
> You might try adding assertions to your actions up at the Bison level.
> If all is as you say, then
>
>       block_expr '\n'
>       {$$ = new_expression(exprBlock, 1, $1);
> 	assert( $$->type == exprBlock);
> 	}
>
> should be true and
>
>     | block_list block_expr '\n'
>       {
> 	assert($1->type == exprBlock);
> 	assert($1 != $2);
> 	expression_add_child($1, $2);
>
> should be true.
>
> 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.
>
>> and more surprisingly, $1 == $2
> 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.
>
> HTH.
>