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.
