[Rust] Random tests sometimes generate an empty vector vec![] which doesn't match the Kata description saying that an empty matrix is represented by vec![vec![]]

Unfortunetly, I have an exception when array is empty (c#) it seems like a test case defect.

In Go is the input supposed to be named "snaipMap" instead of "snailMap"?

C translation has confusing initial code which is NOT illustrating what the user should return

  // Return a heap allocated array, report the size in *outsz
  return (int *)(*outsz = 0);

Is it just me or the empty matrix solution in GO give some problem?

"should return empty array given an empty array" - why does this mean that the array is not empty, but the first element of an input array is an empty array? lang Go
[]int{} -- empty array
[][]int{{}} -- is NOT empty, but kata assumes it is, but the input itself is wrong: it is not 0x0 or 1x1, it is 1x0, but not NxN

D translation

Hi, my golang solution passes all tests except random ones. However, I checked with a size of 6x6, it works. Are there any problems with kata tests on golang?

It's a very good kata, but I find weird that a len 0 array gets represented as [ [ ] ] since that would make a 1 x 0 grid, yet the description clearly states that it's an n x n grid.

Yes, I know it says at the bottom how it's represented. It still makes no sense.

I had to make an additional if statement to my solution so it would pass the empty array case, if it was just [ ] (0 x 0) it would've passed without the need of an additional if, as my solution (and many others from what I've seen in other comments) works for all grids n x n, what the kata asks for.

I'm rating it as somewhat satisfied instead of very satisfied because of that. I'll rate it very satisfied if it get's changed.

• Ruby 3.0 should be enabled (Refer this & this for more detail)

Doing the NASM version

There is no explanation what the parameters actually are

In the starting source there is

  ; <-- [dword RAX] snail([qword RDI] outsz, ro [qword [dword RSI]] mx, RDX m, RCX n) -->

No explanation there, in the testcode or in the description.

I guess I will just have to experiment how it's supposed to be.

In the C-version, which I did solve, there's this comment.

  // the numbers of rows and cols are passed separately for historical reasons

Does it apply to the NASM version as well?

well, i feel like idiot to be honest i just can't get what exactly i have to do i mean i can't get what exactly the question is