should be fixed, can you check ?

Resolved with fork above approved

i can confirm that the random tests in C produce garbage due to a faulty pointer dereference. however, you can still pass the tests as you do not need to print or strcmp the array elements, but merely swap them

fixed here

there's a link under the comment that says "View Solution"

that link is only there when someone has the right language selected and has already solved/forfeited the kata for that language. Besides, since it fetches the solution of your most recent attempt (regardless of whether it passes or not), it is not reliable.

Anyways, I completely rewrote the C tests suite, it should be OK now (old solutions are still passing, at least the author's)

Okay, the tests suite in C is seriously messed up. I have to rewrite it from scratch.

how am i supposed to debug anything with that kind of issue report ? you basically say "my solution was not supposed to pass but passed, there might be something wrong, or maybe not, and i'm not giving a link to my solution" :(

yeah, sorry again, I had not read the description toroughly. It should be ok now.

i did not notice that length == width was out of specs when I rewrote the C tests, my bad. I just fixed that, though I think it does not make a lot of sense to rule out this case (it's not even an edge case per se)

I tried your solution and many others and everything worked fine.

Changing the requirements was the wrong solution. Test suites should not take more than 20 consecutive numbers to concatenate, and if the first number is < 1e7, the string would have been < 140 characters.

The C test suite broke the kata. This is why you have to document the internal requirements of your test suite, and check that translations do not break them before approving.

the condition has been changed

as a short-term fix for the problem, I can change the condition, but the test cases in C have been checked for a long time, I think there should be no errors in them. Anyway, thanks a lot for your cooperation

At least one of my problems was that I returned the empty string as a constant instead of allocating it, and many of the other invalidated solutions do the same.

Yes, some months ago I improved the C tests suite. Among other things, I made it so the tests free the user string even when it is empty, because returning different types of memory (static strings and heap-allocated) from the same function is usually very bad design.

So I thought, maybe that alone loads the freshest test cases, otherwise the tests are stored along with the Move History, so the old tests are "grandfathered in" with all their problems.

Yes, this is what is happening. This is an intended behavior, as far as I know: Kumites started from an existing kata solution copy the tests suite in the state as it is when the Kumite is created. But when you fork an existing Kumite, it is the forked Kumite's tests cases that will be used, even if the kata itself has changed in the meantime (this behavior is the same for kata translations: forking one will not pull the most recent kata state).

I copied them out and diff'd them, and they're the same.

I cannot replicate this, I do get the newest tests cases when I fork your obsolete solution directly (as opposed to forking from the move history page). I think you most likely made a copy-paste error when you diffed.

please add a link to your solution that should not pass the random tests, otherwise we cannot do anything