On Wed, Jun 03, 2026 at 05:01:02PM +0100, James Clark wrote:
[...]
+# Remove open brace lines as they may not be hit depending on the compiler +sed -i \
- -e '/deterministic.c:8$/d' \
- -e '/deterministic.c:15$/d' \
- -e '/deterministic.c:23$/d' \
- "$tmpdir/script"
Is this related to the function definition?
I can see the brace lines with change below. It might be more reliable if adding unused function argument, which can give chance for hit function entry.
static int function1(void) { ...
return 0;}
Originally I included the brace lines in the test and it was working even without function arguments, but Sashiko mentioned that they may not always be hit.
I tried Clang to build the program and can see the brace lines are missed for function1() / function2().
Does Sashiko mention any reasons causing the issue?
I think its point was that there is no hard rule about debug symbols for open braces and the behavior might change from one version of the compiler to the next, or whether there is a function prologue or inlining or not etc.
I don't think it's important to the test at all though? So to err on the side of caution it makes sense to not test for them. Unless there's a reason you think testing for open braces is important? Surely just testing for actual lines of code appearing in a certain order is enough.
As the test program is named as "deterministic", wouldn't we expect the test to hit every code line run in the program?
It is fine for me to skip some checks _if_ we know the reason. I dumped the disassembly, it shows function entry is a distinguished position from the first calculation sentence (same for both GCC and Clang). And there have no difference for a function entry after I tweaked the function return type from "void" to "int". I still have no clue why brace lines are misses.
Thanks, Leo