Awesome use of the REX prefix! Nice way to use NOP to form UTF8.

This was quite a challenge to pass all tests with distorted inputs. Took more time than expected. Really nice kata!

Wow! No need to get personal here about my translations. I did use pointers you say? No way!

I've always responded to issues raised about my translations, and I keep things clear for the end-user. That was what this comment is about.
If you can't handle criticism about how to improve upon such a simple thing, especially for more inexperienced users, you have bigger issues to deal with.

Relax man.

• I don't care too much about "preferred way",

  • And I do not care too much about your preferred way. Language-agnostic descriptions are encouraged on Codewars, deal with it.

• There's not much that leads to "maintenance issues" with that.

  • You do not know about maintenance issues, because you do not maintain your old C/C++ translations (which have quite a few issues. I know, because I have had too fix and maintain a lot of them, many having very poor design, writing C++ like it's 1998 with pointers all over the place, no instructions on memory allocation, poor assertion messages and uncomprehensible, golfed code in the test suite. It's really revolting to see you complain when the tiniest thing in a kata does not go your way, while you authored all this mess and are never going to fix it.). So do not bring up maintenance when you are not the one maintaining things.

• Clearly the function off doesn't return an array at all

  • Which is to be expected for a C kata, since passing arrays as output parameters is idiomatic in C.

Before I erase the code, I read it, thank you.
It doesn't explain it as you claim:

#include <stddef.h>

//  assign values to pre-allocated *array
//  *array allocation fits up to length n
//  return your array length as an output

size_t off(unsigned n, unsigned array[n]) {
    size_t length = 0;
  
    //  <----  hajime!

    return length;
}

A quick read shows that array length is n. You mean something different, which took some time to discover. Please be a bit more clear. Also it's missing from the Description, which says:

Create the function off, that receives the nth switch as argument n. The function should return an ascending array

Clearly the function off doesn't return an array at all, so the description is inaccurate.
I don't care too much about "preferred way", as I've written plenty of C translations where I adapted the description for C specifics. There's not much that leads to "maintenance issues" with that.

Other than that, thanks for your efforts.

Brute force solutions like this really should not pass a yellow.

Tests need significant hardening.

Once again, you erase the instructions in the initial code without reading them, stop doing that. Per-language instructions are supposed to be in there on Codewars, as putting them in the description leads to maintenance issues. This is the preferred way to do this and has been for quite some years now, get used to it.

The API is not strange. You have a buffer of length n, write your answer to it and return the actual length of your answer (which will obviously be <= n as per the problem statement, since you are removing elements in a list of numbers from 1 to n). All of this is explained in the initial code.

C translation has really strange API and expected return value is not mentioned in the description, and is the same as input parameter n??

delete...

delete...

delete...

in C: random tests don't excite all paths in solution, allowing incorrect code to pass all tests.
Some cases not covered by default:

  dotest (16,8448,8449);
  dotest (7,5935,4);

but others might also be missing. You can try to find them by running tests 10+ times.

fixed

duplicate of this issue

Fixed Coffeescript and Ruby too.