No, if possible, returning a value from a function is to be preferred over storing it in a pointer.

This is nonsensical in C. The current setup is really bad as it hides a pointer to an array behind a typedef (which is pointless as the number of rows does not even vary...) even though the function has to know the precise memory layout of the type, so nothing is abstracted away. The signature should have been:

void solve(const int input[9][9], int output[9][9]);

C Translation
ready for review.

Is there anything else needed for approval?

Yes. This is the fork to approve. I have just finished adding the suggestion you made with the not null assert, so it should be ready.

That does seem cleaner. I was unaware of this assert before, so thanks for pointing it out.

in some places you have a pattern of:

if( someptr == NULL ){
  cr_assert_fail( "canot be null" );
} else {
  ... more testing code...
}

It could be probably replaced (or at least I think so) with

cr_assert_not_null(someptr, "cannot be null");
... more testing code...

Would it be this fork to be approved?

So if no one else has any comments/additions, will this be approved?

@nomennescio I swapped out slightly ugly syntax in favor of a typedef typedef int (*SudokuBoard_t)[ 9 ].

In addition, the relabeling now permutates 1-9, instead of only swapping 3 pairs of integers.

@Bats6789 as for formatting, you can pick any style you like, look around at some code of others, what you think is most readable.

As for relabeling, I think it should apply to all numbers i.e. do a permutation on 1-9.

@Hobovsky Ah, I see, I missed the "easy that can be solved by brute force" tag.

@hobovsky the translation now applies some random relabelling like so

for( int j = 0; j < 3; ++j ){
  a = rand();
  b = rand();
  if( a != b ){
    relabel( puzzle, a, b ); // change all a->b, and b->a
    relabel( answer, a, b );
  }
}

The relabeling occurs before every transformation that was there before. So effectively the steps are:

1. grab a pre-written puzzle and solution
2. relabel puzzle and solution the same way
3. transform puzzle and solution the same way

Is this a sufficient relabeling/randomization strategy?

@nomennescio What would be the standard format? I'm willing to modify the code to comply with the standard.

Generating a solvable sudoku of a specific difficulty is hard. It was tried by other translations, and general consensus is that's it's too difficult to do reliably. As an alternative, other translations (and I advised to do the same thing here) is to use some predetermined boards and transform them randomly by relaellings, rotations, and swapping row/column triples. As far as I see, the translation does not do relabellings, which, I think, have the biggest "obfuscation" potential.

If you can come up with a reliable way of generating easy, solvable boards, feel free to share.

That looks much better, although I find the formatting a bit non-standard, but I'm willing to ignore that.
However, the random tests are basically scrambling a pre-calculated solution, which is not random enough.
I expect that you fill a random puzzle, and call your own solver to find the reference solution, and test the user's solution against that.

@nomennescio I decided to convert to a contiguous 2D array. It was a fun little learning experience for me. Everything should be converted over now.