I've reset my solution, and indeed the sample code did change.

That's defeinitely not the current sample tests, which is cr_assert_str_eq(*(actual + 1), "0", "0 %% 5 == 0");.

First warning is:

fixture.c:8:49: warning: invalid conversion specifier ' ' [-Wformat-invalid-specifier]
  cr_assert_str_eq(*(actual + 1), "0", "0 \x25 5 == 0");
                                          ~~~~~~^

To me the hex escape seems weird.

Weird, I'm just running the default sample tests.

I can't reproduce this. Are you using the up to date test fixture?

It seems the C translation still has compilation warnings : "invalid conversion specifier" in fixture.c

How is this NOT cheating?

Glad you like it, hope you find some inspiration in it

wow

Bloody heck! Again? I really need to be careful to check the countdown case from now on! Well done.

Darn! Ye olde counting backwards again...

You mean my first programming languages?

No, it was a pun. Sorry.

You mean my first programming languages? I think it would be Basic, Assembler, and Forth.

What were your first three inheritances?

Most likely it indicates that your code runs out of time, as the input n is in range [0, 10e6] and (10e6)! has more than 50e7 digits. Both computing n! (multiplying for big integer is expensive too) and extracting digits from n! by dividing 10 forms performance bottleneck.