Yes, it is intended that you account for these cases, as they are included in the edge case tests (although not in the normal sample tests). I have updated the description to reflect that.

It would be nice if the description clarified the relationship between cmp and subroutines (i.e. should subroutines affect the value of the parent "most recent cmp" or get their own). I don't believe this case is tested either way, though.

Shit, I was running this in two windows. They are added now.

Dang, I just can't get this right. I believe I've fixed this, thanks for your patience.

Fixed all, thanks.

It might be nice to get some moderate size random tests (maybe array size 25 or so), since there are many cases which might pass the static tests but fail random due to logical errors, not timeouts. As it is, it's almost impossible to actually debug in the test suite without just writing my own random tests.

Fixed. I've changed the fixed tests to match the Python version (these were from C#).

C Translation is ready (author is inactive).

Also, the random tests in C# seem really bizzarre, and I don't think they're doing what the author intends. They appear to be running 7000 tests over the same set of 2000 arrays, and none of the test sizes come close to the JavaScript performance tests. I'm hesitant to change them, though, as many existing solutions could start failing due to signed integer overflow.

@kissgellert6 So I haven't actually checked if there are logical errors (it looks fine generally, I think), but the first thing that stands out to me here is that you appear to be returning p, which is a pointer to an array defined in your function. This is generally a bad idea, since arrays are stored in the stack. Basically, the array p is pointing to is in "temporary" memory, which could be cleared or reused after the function returns. You can avoid this issue by instead allocating space on the heap using malloc or calloc. The resources I linked are just randomly selected from google, but if you have a book you're working from, it probably has a chapter on this.

Just for example, you have the line

char answer[250]={0}; // answer points to 250 bytes on the stack

I suspect you'll have different results by simply changing that to

char *answer = malloc(250); // answer points to 250 bytes of writable memory on the heap
// or
// char *answer = calloc(250, sizeof(char));

Also, you can mark code blocks using three backticks (ex: ``` some code ``` ), which makes things more readable.

@kissgellert6 Can you be more specific about what didn't work? If you want, you can post your solution I can take a look at it.

To be fair, this is basically a direct translation of my JS solution done twice to allocate memory. I couldn't bring myself to remove the gotos, they bring me such joy.

I probably should have tried harder.

Hey, any chance of getting this passed through?

Does this one work?

Updated the tests, thanks.

@Chrono79 I have forked this and fixed the random tests, not sure if it can be integrated or if that's of any use.

https://www.codewars.com/kumite/5da194ad8fd3c9002af1d7d1?sel=5e7148d4251098002809afd6