You'd have to add something to the description along the lines of "In this kata, you are expected to write a function which can take either zero or one parameters." Even then, people tend to be bad about reading the description. I think the main problem is that this kata is introducing a concept that seems to be new to newer programmers, but it's not explicitly calling out what that concept is. A lot of people solving the kata aren't even aware that what it's asking for is even possible, so it doesn't register to them as "this is something I can control". Another idea might be to have the tests catch the exception and print out a more user friendly error message that says something like "Your function doesn't work when called with no arguments." A lot of people reporting this as an issue seem to have a problem comprehending error messages. At the same time, that's a skill they should be working on, it's not really reasonable to expect kata authors to have to do that just because a lot of solvers lack a basic programming skill.

This is not exactly what I wanted to ask. I would be interested to know what to change in the kata (in the description or in examples or something) so users will see their errors as their mistake, and not as a bug with the kata.

For example what made you think that the kata is buggy? What would help you see your mistake?

For hobovsky's question on how to help with the responses, I suggest instead of saying you are wrong, saying "the Kata is not wrong, if you are having issues tag the post with question".

Angry? I just left some snarky replies to your equally ridiculous comments, while trying to point you to the source of the error.

And no, we can't just ban you because we want to (I'm not sure about Hob), but the fact you would just blindly imply it is quite disgusting.

You are expected to return a dynamically allocated string.

You are right that returning internally allocated strings is a poor design choice, it is unfortunately a long established convention for C translations of Codewars challenges, especially the older ones, created by translators who either did not know what are valid patterns, or simply did not care. Fortunately, currently active C translators came up with much saner setups, like preallocated output buffers, mutable buffers, and generally much better and idiomatic setups.

If you see a C translation which requires you to return a pointer and no explanation how it could be allocated, most probably you have to dynamically allocate the buffer. And still this is not the worst kind of a setup: there are some old setups which require you to return a malloced buffer of... pointers to individually malloced ints. And they do not describe this aspect at all, you need to deduce it from errors. Those are fun.

When using C, the test case expects a pointer type string, the problem with this is that any value you attempt to return will be the address of a local variable that will then be available memory for the program on exit, in other words, the value of the returned string will be erased or changed. I would allocate memory for that purpose, but this will be a bad behavior as I'm not in control of when to free the allocated memory. Has anyone tried it on C? Maybe using ENV variables?