Yes, that way the original array that was passed in as a parameter is not modified.

Performancewise would be "better" to use a StringBuilder or StringBuffer (using the .append() method) as it is faster to reallocate memory for a growing object, than creating a new object in each loop iteration.

Yes, it is working. But it also mutates the inputArray, which might be unwanted and is considered bad practice. It would be better to keep the function pure and return a new array instead.

it crashes when you run it against the sample tests (button TEST), and passes when you run it against the full tests (button ATTEMPT). The sample and full tests are independent (they are in separate files).

• The sample tests are the ones you can see on the Trainer page; they are only here so that you can get an idea of how your solution is called and which kind of inputs you can expect.
• The full tests suite (which you cannot see unless you completed the kata) are used to determine whether your solution is correct or not. It does not matter if you pass the sample tests or not to complete a kata.

usually, the sample tests are also copied to the full tests suite, but this is just a convention and authors can write tests differently. In this particular kata, the author of the C version did not do this: the sample tests call the user function with read-only string literals (which crashes this solution), but the full tests call it with mutable strings, so this solution can get away with removing const

Thank you for the good explanation. But my question was, why exactly this above solution does not execute properly? If I run it against the tests of this Kata, I get the SIGSEGV. Did some compiler change here?

this solution casts away constness, which is mind-bogglingly bad and should never be done. it does that to pass the string to the strtok() function, which mutates the string it receives as argument.

You probably tried to call this solution on a read-only string. on most platforms, string literals are placed into the .rodata (Read-Only Data) section of a program, which is where the compiler stores compile-time constants. attempting to modifying a .rodata object at runtime results in a segmentation fault (the OS crashes your program)

wrong:

mutating_func("abc"); // crashes
char *s = "abc"; // omitting the const has no effect here, it's still read only 
mutating_func(s); // crashes

correct:

mutating_func((char[]){"abc"});
mutating_func(strdup("abc"));

This solution gives me a SIGSEGV (11) error. Same as my original solution did.
What is wrong?

What about these magic numbers 15 and 20?
I am not an experienced C programmer, but I think it limits the input to a number with 15 digits? I think this should be implemented more generic to be "Best Practice". It is not a big deal to get the number of digits of an int.

Am i wrong?