Putting the string on the heap is important since we need writable memory. If you were to use so-called VLAs (e.g., a string allocated on the stack you could get non-writable memory). In C stack-allocated strings should be considered immutable.

?!

You can absolutely have mutable strings on the stack. char buf[11]; would work just fine for both your solutions.

Seems like you got pointers and arrays confused. A pointer to a string literal (stored in the data segment) is not a "stack-allocated string". There's a significant difference between const char *foo = "bar"; and char foo[] = "bar";.

VLAs don't particularly factor into this, but they are absolutely mutable (seeing as they cannot be initialized, they would be useless otherwise). There is no such thing as "could" when dealing with well defined behaviours.

I think that making it static would not be a good idea.
Putting the string on the heap is important since we need writable memory. If you were to use so-called VLAs (e.g., a string allocated on the stack you could get non-writable memory). In C stack-allocated strings should be considered immutable.
Thus, going with malloc/calloc is a good idea here. Also freeing usually is implemented to be almost constant time, so there's no need to worry about that.
I hope I didn't misunderstand what you meant by static :'D

Can anyone please write the full
program!

I agree.

Parsing the number is costly compared to iterating over each digit with modulo and division by 10. This does look elegant though.

Right. If all solutions here are treated as passed, then current test cases are not enough.

I've been doing garbage collected languages too much. I'd probably make it static rather than just adding a free for performance.

this will leak memory if buf is not freed

I had the same problem in Chrome on Mac, but only if dev tools was open. Closing dev tools rendered everything properly.

Further experiments show that when it happens, it always happens on the array of length 12345 and crashes on the first array reference.

I revise my hypothesis. I think that there is an unchecked memory allocation failure in the test driver and that sometimes the memory allocation for the test array fails.

I was getting sporadic failures in C with the resulting message "Test crashed" which I suppose you'd classify as a server failure. I've only encountered that in situations that seg fault. The only place in the code that I can see an unchecked reference against bounds is an assumption that there will be at least two elements in the array, so I don't do any bounds check for an array[1] reference.

Are you getting test failures? or server errors? also - which language?

I think the random tests are creating single element arrays, which should not be possible if there is always a definitive answer as it wouldn't allow you to determine ascending/descending. I kept getting sporadic crashes in my runs preceding final submission and can't come up with any other way it could happen besides my referencing the second element of the array without checking bounds.

Does this work for "1110000000111" a.k.a. "- -" a.k.a. "T T"?