If you are interested, you can see PoC of my idea here: https://www.codewars.com/kata/reviews/5e072bf6bb26620001ec1da9/groups/5f458d53e0be5a0001d0e55d

I also agree about leaving the allocating to the caller - but this is not (?) realizable within this Kata.

Unfortunately, not.

The 'numbers test' in C has strings made out of ASCII numbers that are randomly generated. This is tested for the fact that numbers or non-alphabet characters should be ignored in the function. If you're geting 15 lines of 10 random numbers from printf() or puts(), everything's alright.

Nice insight, didn't think of that.

My solution was a clear case of "Wait, it works, but what about the memory" - and I chose the path of least resistance and brain usage.

I also agree about leaving the allocating to the caller - but this is not (?) realizable within this Kata.

I am not a professional C developer, nor embedded developer, but I do not like your approach either. First of all, length of resulting string can be calculated exactly, going once over the string. Just use newLen = strlen(input) - count('#') (handling #s close to the beginnig of the string appropriately). If, for some reason, you want to really avoid over-allocations, then calculate length of the result first, and fill in the buffer later. Nothing gets wasted this way, on no stage of the operation. Your solution needs twice as much memory at some point, because for short time it keeps initially allocated "too long" string, and later allocates a buffer of "appropriate" length, having two buffers. You can avoid it by expense of precalculating the required length.

Other thing is that allocating the buffer inside of solution is not that good in itself. I think it would be better to make allocation responsibility of the caller (after all, caller becomes the owner of the buffer anyway), and caller could even use some kind of preallocated memory pool to keep the result and avoid necessity of freeing it, or avoid problems with memory fragmentation, etc.

Most solutions I find to this in C seemingly are inefficient with memory. They allocate memory according to the length of the source string, and make no effort to clean up the memory later. I'm primarily an embedded dev, so I'm very concerned with memory use if I can.

My solution cleans up the memory afterwards by duplicating the string (that's terminated, but has too much memory allocated to it) to another pointer, freeing the original (longer than necessary) string and returning the size-optimized string.

What's your opinion on this? Of course, if this is all used in a local environment that temporarily exists, which properly frees memory by some mechanism after it's done it's job. Then it's no problem. But if this function is run many times without freeing memory, my cleanup will use up less memory in exchange for a bit of processing time.

What's best practice? Assume that output strings are only used temporarily and freed later, or make the strings effectively use space at the expense of processing time?