I like your sete. Good thinking!

Didn't know I could test it that way, nor did it occur to me - thanks!

This is interesting, because "Fixed tests" and "Small strings tests" should present you the input of failing tests.
Sample tests (the ones run when you click TEST) do not present inputs, but you can add and remove test cases and assertions to see which one trips up your solution.

In your case, it's this one: assert.strictEqual(scramble('katas', 'steak'), false);

JS: My code passes all large tests, but fails a basic one with the error output only showing "Expected true to equal false" - any ideas?

I found my mistake. Keep an eye on your register sizes. I started with 8bit regs, and only switched to 64bit regs when I saw the random long str test. I simply forgor to change 1 line to get a 64bit value and not only 8bit.

NASM. My code solves all BasicTests and RandomTests. TestsStringsUpTo40kLenForPerfomanceAssesment then fails on the first tested string pair. It is not a time out, it says "Incorrect answer for". Any ideas for potential pit falls when handling these very long strings?

Approved by someone

NASM translation Please have a look at it.

In addition to monadius note. I tried malloc before and I got a sigsegv. I doubted malloc at that point, but it was a special case that caused this crash. So for anyone else struggling, watch out for special test cases. There is a sneaky one.

Thanks for the clarification. For some reason I expected that it is intended to use the RDI-pointer not only for the length but also for the result arr. Have a nice day.

The result is a dynamically allocated (e.g., with malloc) array. The address of this array should be returned in rax. The length of this array should be written into [rdi].

I recommend to solve this kata in C first because the C version has the same requirements as NASM.

NOTE: Extra spaces before or after the code have no meaning and should be ignored.

Another thanks for your explanation and your provided link. Have a nice day.

Because your code is too slow for big inputs:

Take a look at performance: some lists have thousands of elements.