it is very likely that one hand get used multiple times

So, that's it! Thanks, now totally explained.

In all of the initial tests Hands are created, tested once and then freed. That let me to the assumption that it would always be that way. My mistake. Thanks again.

yes, but what is the issue here ? you modify tracker yourself, so you mutate the state of your Hand object. then at the next call with the same object, of course the mutations will persist. take a look at how the random tests work, all of the hands are built beforehand and are played against each other at random, it is very likely that one hand get used multiple times, hence why the changes persist

Thanks, but that result would be expected - buildTracker() should indeed set values into the tracker field.

Let's use your test approach, but before any calls to buildTracker:

Result compare(Hand *pl, Hand *op) {
  int checksum = (pl->tracker == 0) + (op->tracker == 0);
  // Both tracker values were set to 0 by PokerHand, so they should still be 0 now.
  assert(checksum == 0);

  // tracker fields will be updated by buildTracker().
  pl->type = buildTracker(pl, pl->cards);
  op->type = buildTracker(op, op->cards);
  Result retval = _compare(pl, op);
  return retval;
}

Output includes:

boxfort-worker: solution.c:199: Result compare(Hand *, Hand *): Assertion `checksum == 0' failed.

it seems to be your own code that modifies the tracker field though, I slightly modified your test in compare():

Result compare(Hand *pl, Hand *op) {
  int checksum = (pl->tracker == 0) + (op->tracker == 0);
  pl->type = buildTracker(pl, pl->cards);
  op->type = buildTracker(op, op->cards);
  Result retval = _compare(pl, op);
  int new_checksum = (pl->tracker == 0) + (op->tracker == 0);
  assert(checksum == new_checksum);
  return retval;
}

the assertion fails.

This code does not really confirm anything because we do not know how your real code, the one which breaks things, looks like.

Seems not fixed to me. I was given the test:
"JC 6H JS JD JH", "JC 7H JS JD JH"

Both hands contain 4 Jacks. For this to be possible, there would have to be at least two decks of cards in use. To be fair, the description does not specify whether a single deck of cards is used, but I think most people would assume that's the case.

I agree, the correct solution for 96682790625023136 is { 9668279062523136, 11, 0 }

Tested with large random integers, this seems to be about 100 times the speed of some solutions here - those using strings and brute force.

Thanks for the feedback. I was running your code to test it... maybe I made a mistake and forgot to compile and it was somebody else's code :) I'll check again when I've got a moment.

Are you sure? b7 to a8 return 4.
If begin OR end position is a corner point (A1,A8,H1,H8) AND BOTH row and col are 1 step, we've a minimum of 4 moves.
This covers the moves A1-->B2; B2-->A1; H1-->G2; G2-->H1; A8-->B7; B7-->A8; H8-->G7; G7-->H8
For all other 1-1 moves, you will not fall in the second IF case and it returns 2 moves.

I play with the ASCII value: 'a' = 65, 'b' = 66... 'h' = 72; '1' = 49, '2' = 50,... '9' = 57
It doesn't matter if we move from a to b or b to a as ABS(66-65) == ABS(65-66) == 1; same for the digits.

Despite passing tests here, this solution is flawed. I'll fix it when I get a moment.

Try testing all possible moves - you will find it fails on 8 of them.

If you test it with all possible moves, you will find it fails 8 of them, returning 2 when it should be 4.