From c797f6406d35d4017bf0edff58efd956fa676571 Mon Sep 17 00:00:00 2001 From: Kevin Day Date: Sun, 31 Jul 2022 17:50:30 -0500 Subject: [PATCH] Bugfix: Block is incorrectly being reset when an else condition precedes an if condition. There is a logic mistake where the "else" is not being considered when determining when to reset the block. This results in the block states being reset when the previous operation is an "else" condition. This results in the second else condition potentially running even if the prior condition already ran. This was discovered when investigating Github actions test failures that pass locally. The Github actions tests use a special test argument that I had not tested locally with. --- level_3/fake/c/private-make-operate_block.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/level_3/fake/c/private-make-operate_block.c b/level_3/fake/c/private-make-operate_block.c index 37fc960..38b7da2 100644 --- a/level_3/fake/c/private-make-operate_block.c +++ b/level_3/fake/c/private-make-operate_block.c @@ -13,8 +13,8 @@ extern "C" { if (state_process->operation == fake_make_operation_type_if_e) { - // When another if condition follows a non-if, non-and, and non-or, then this is the start of a new condition block. - if (state_process->operation_previous != fake_make_operation_type_if_e && state_process->operation_previous != fake_make_operation_type_and_e && state_process->operation_previous != fake_make_operation_type_or_e) { + // When another if condition follows a non-if, non-and, non-or, and non-else, then this is the start of a new condition block. + if (state_process->operation_previous != fake_make_operation_type_if_e && state_process->operation_previous != fake_make_operation_type_and_e && state_process->operation_previous != fake_make_operation_type_or_e && state_process->operation_previous != fake_make_operation_type_else_e) { state_process->block = fake_state_process_block_operate_e; state_process->block_result = 0; } -- 1.8.3.1