Nobody's going to change the kata in the way you suggested years after it was approved.

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");
}

Thank you for your comment. Unfortunately, it is probably too late to make changes to the problem condition, since all decisions of users who used the libraries will be invalid. I will definitely consider your proposal in the future.

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! :)

Mine is O(logN), in Python. It's a binary search.

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