Will fail in case nodes addreess are not monotonically increase/decrease:

Test(SampleTests, TwoNodesTileFourNodesLoopRandomOrder) {
  Node n[6];

  // 4 -> 1 -> 3 -> 0 -> 5 -> 2
  //           ^              |
  //           +--------------+

  n[4].next = &n[1];
  n[1].next = &n[3];
  n[3].next = &n[0];
  n[0].next = &n[5];
  n[5].next = &n[2];
  n[2].next = &n[3];
  
  Node* startNode = &n[4];
  int actual = loop_size(startNode);
  cr_assert_eq(actual, 4,
    "Incorrect answer for TwoNodesTileFourNodesLoopRandomOrder");
}

Will fail in case nodes addreess are not monotonically increase/decrease:

Test(SampleTests, TwoNodesTileFourNodesLoopRandomOrder) {
  Node n[6];

  // 4 -> 1 -> 3 -> 0 -> 5 -> 2
  //           ^              |
  //           +--------------+

  n[4].next = &n[1];
  n[1].next = &n[3];
  n[3].next = &n[0];
  n[0].next = &n[5];
  n[5].next = &n[2];
  n[2].next = &n[3];
  
  Node* startNode = &n[4];
  int actual = loop_size(startNode);
  cr_assert_eq(actual, 4,
    "Incorrect answer for TwoNodesTileFourNodesLoopRandomOrder");
}

Thanks for the kata! Although it would be more difficult and more fun if imports were disabled :)

Nice kata, thanks! A couple of comments:

1. For the better value I'd suggest to disable date/time libraries. The task is really worth to think a little bit about numbers crunching rather than to find a ready-made solution.
2. There is a simple O(1) solution without loops, dictionaries and conglomerates of "if"'s.

Exactly! :)

Very nice kata, thanks!

Wow, nice to see the reference to Uncle Bob, I like this guy too :) Totally agree.

Very nice kata, thanks a lot!

Have someone implemented solution with better than linear (O(n)) time complexity?

The probem is that in expression d = a/n; 'a' is (signed) int but 'n' is size_t (which is unsigned long). As unsigned long (64 bits) is longer than int (32 bits) the intermediate computation is performed as unsigned long. In case 'a' is negative (i.e. the most significant bit is 1) after conversion to unsigned long it would be a big positive number with 31st bit == 1. After division this bit is shifted right and the new 31st bit will be 0. After converson back to int (assigning to 'd') the result would not be negative any more but an "odd number" :) To fix the issue use d = a/(int)n

Nice kata, thanks. Though, the description doesn't specify the behavior in case of an incorrect format string (e.g. "{" (single open bracket) or "{i" (incomplete type specifier)), neither the test suite verified such test cases.

In case the format string is "{{i}" the output should be "{i}" (as the beginning "{{" should convert to "{" and the remaining "i}" is not a format specifier anymore and should copy as ordinary characters). Looks like in your solution the result would be "{<some_number>".