Yes, it's a trade off.
In your solution, which does not waste memory, you check the whole string twice.
Another solution would be to first create the wasteful buffer, write the solution into it, now determine the actual size.
Create a new buffer, copy the string from the wasteful buffer, free the wasteful buffer, return the new memory optimized buffer.

But hell, we are optimizing something really tiny and even if the string was quite large, then this third solution would be problematic, because temporarily you need almost twice the memory.

Unused memory isn't leaked. There's just a bunch of undefined bytes after the null byte. It still gets freed when the memory is freed using free, since the OS keeps track of the number of bytes allocated when you call malloc.

Imagine if this was an int array not a char array, a 0 in the middle of the array wouldn't cause any memory to leak.

Code size optimization

I guess we can close this question. If you have any further questions, feel free to open a new one :>

The argument should be in EDI register. The calling convention is in the order: edi, esi, edx, ecx.

Ah ok I see. IterTools.step is depricated, so one should use std.step.by() instead, and then no imports are needed.

I just retested, removing extern crate itertools is possible, but if I remove use itertools::Itertools; I get the error:

error[E0599]: no method named `step` found for struct `std::slice::Iter` in the current scope
 --> src/lib.rs:4:22
  |
4 |         array.iter().step(2).sum(),
  |                      ^^^^ method not found in `std::slice::Iter<'_, u32>`

error[E0599]: no method named `step` found for struct `Skip` in the current scope
 --> src/lib.rs:5:30
  |
5 |         array.iter().skip(1).step(2).sum()
  |                              ^^^^ method not found in `Skip<std::slice::Iter<'_, u32>>`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `challenge`


NOTE: Line numbers in error messages can be incorrect due to concatenation.

I would guess that when the solution was made extern crate itertools; was nessesary. Rust 2018 removed the need for extern crate in a lot of cases.
Thanks for the comment!

You have the ability to refactor before, and to fork after submitting :)

That is true. Forked version is better.

You need a solution which is faster or does not use up so much memory.