I still see unsigned in the function signature and the description still has "Values up to n = 200 will be tested." ??

C translation doesn't actually calculate the requested Kata outcome, because the result doesn't fit the unsigned return type.
Either limit the input for the C solution, or use larger return types (or both).

C translation doesn't show expected value, only "Incorrect Result".
Not sure if this is intentional, but usually that's not acceptable.

the i++ is undefined behavior

LOL! I made it my personal challenge to solve all Codewars C problems with short but readable solutions. I've developed my own style throughout the years, which is not to everyone's taste, but I obviously like it. I'm almost there, but am now stuck with the hardest problems... It requires more of my time to solve these remaining problems, I'm not sure I will have enough time.

There are lots of interesting problems out there!
See if you can solve https://www.codewars.com/kata/5993c1d917bc97d05d000068/c

Thanks, first time I've encountered someone quoting Latin proverbs.
If you like code golfing, why not try: https://codegolf.stackexchange.com/ ?

I think you miscounted, moving the body into the for statement doesn't save any characters.
As for K&R style, I don't like it, and it is removed from C since C23.
As for the header, size_t is compiler dependent, so there's no portable way to drop the header. I usually don't care too much about the includes.

thank you for the upvote

Really nice! Well done!

As for your remark on branchless; you need to check your code in godbolt to see what it does; have a look at https://godbolt.org/z/TK1xMj66d
Furthermore, almost all current CPUs have branch prediction, so if you measure performance, it might be different from what you would expect.

Nice! That third ternary operation indeed was a "code smell".

For golfing, I ignore whitespace, and with the new C versions, K&R C isn't supported, so I prefer still rather formatted code.
A recursive solution is fine, but a simple for loop is good as well.

If I compare both, we have:

int sum_digits (int n) { int s=0; for (n<0?n=-n:0;n;n/=10) s+=n%10; return s; }

and

int sum_digits (int n) { return n?abs(n%10)+sum_digits(n/10):0; }

but the include for abs isn't used, if it's added we get:

#include <math.h>

int sum_digits (int n) { return n?abs(n%10)+sum_digits(n/10):0; }

which is actually a little bit longer, hence making my code shorter looking from that perspective.

Both are fine solutions however in my opinion.

Tests for C++ should give the same results as the tests for C for the same inputs. It doesn't.

Is fixed, thank you!

C++ (sample) test code does not support pairs. Consider dummy solution:

auto divide_strings (const string& a, const string&  b) -> pair<string, string> { return {"0","0"}; }

The following test code passes:

Describe(your_divide_strings_function) {
  It(should_work_for_some_sample_test_cases) {
    Assert::That(divide_strings("0", "5"), Equals(pair<string, string> {"0", "0"}));
  }
}

The following test code fails:

Describe(your_divide_strings_function) {
  It(should_work_for_some_sample_test_cases) {
    Assert::That(divide_strings("4", "5"), Equals(pair<string, string> {"0", "4"}));
  }
}

with error

Expected: equal to [unsupported type]
Actual: [unsupported type]

hahaha, that's very creative!