Why incur the overhead of incrementing "*sz" multiple times when you already need to know it for the malloc()?

This is absolutely NOT "best practice", nor is it clever, as it's modifying a const string it will typically crash.

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?

Is the default return value of a function an integer?

That is true. Forked version is better.

This wastes memory (as many bytes as the number of vowels in the string).

another way without the parentheses: ++*sz;

(this will increment the value fetched by the pointer, rather than the address after fetching the value)

Someone else has made the same comment already: s is a const char* parameter. If you cast it to a char*, you allow that it is modified. I think this smells, even if strtok does not change s.