• Lua and C translations lack random tests.
• Lua's function name is not the one used in the tests (startsWith) throwing errors when running the tests.

C++ Translation.

There's a general convention to return zero when everything is ok (one way to do it) or when error has occured (many ways, hence many numbers).

C sample test code has compilation warnings.

Example code that will SIGSEGV the tests, yet has a perfectly reasonable return value:

char **match (const char *p, const char **f) { char **m=calloc (sizeof (char*),1); return m; }

c_ary_eq implementation is deeply flawed: actual being shorter than expected will cause SIGSEGV.

Since you are insisting on modifying the input buffer and return it (which is not tested in any sample or fixed test) you should at least mention this in the description or the initial solution setup. I don't want to guess this from the fact that the signature doesn't declare source as const char*.

This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/147.
Please join the discussion to share your opinions, and help us identify duplicate kata and retire them.

LUA does have a wrong function name in the solution template: s.solution should probably be s.startsWith (except this is part of the kata... which I doubt)

Go translation

D translation

• Description should be language-agnostic

• The five sentence can be classified in a note section and re-worded

The rule asking to remove spaces if input string is NULL doesn't make much sense, and more problematically, it is not tested in random tests.