We should drop mergesort

[NicMcPhee]

The C standard has changed so that you can dynamically allocate arrays on the stack even if the size isn't known until runtime. That means that you can legitimately solve the mergesort problem without using calloc or free, which really defeats the purpose.

We could drop mergesort and combine array_merge into the previous lab, or try to come up with a new problem to replace mergesort.

[NicMcPhee]

A possible alternative would be a new exercise on string wrapping. They could take some sort of text input and "wrap" it to a given maximum line length, returning an array of arrays of chars.

The "obvious" way to get the text would be from reading a file, but that starts to creep into the system call work in the next lab. Maybe read from stdin, although that's nearly the same as reading from a file.

If this is all characters, then they don't have to allocate the exact (correct) number of chars for each line, but we'd presumably want them to. If some of the lines had to be too long (single words longer than the line length, maybe urls), then that would catch them out if they were just allocating 80 (or whatever) characters each time.

My thought is that the result would be an array of arrays, but it's not obvious how we'd know the length of the outer array (the number of lines) until after we've done the wrapping.

A linked list would be reasonable here and introduce structures.

We could also fancy up the exercise some by having them follow that up with a "repair" pass that looks for "short" lines (more than 10 characters under max?) and see if a different break in one of the 1-3 previous lines would improve the situation.