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.

[kklamberty]

Does it make sense to make this a tiny lab asking for just array_merge and give them mergesort? This lab seems to have remained untouched for a couple of years, but I'm looking for feedback before next week. There are probably other things we could do instead of this lab, but I didn't notice this issue until now, unfortunately.

[NicMcPhee]

I like your idea of giving them mergesort and having them write array_merge. It makes a pretty small lab, but it would work.

I think I just kept on with the existing lab after adding the warning saying "don't use the stack" on mergesort and that seems to have gone fine, TBH. I think you'd be totally fine just leaving things alone if you want.

[NicMcPhee]

I don't honestly know if/how Wenkai has used this lab since he took over the course, and you might want to contact him directly on that. I like your idea of giving them `mergesort` and having them write `array_merge`. It makes a pretty small lab, but it would work. I think I just kept on with the existing lab after adding the warning saying "don't use the stack" on mergesort and that seems to have gone fine, TBH. I think you'd be totally fine just leaving things alone if you want.

…

On Thu, Sep 18, 2025 at 7:21 PM K.K. Lamberty ***@***.***> wrote: *kklamberty* left a comment (UMM-CSci-Systems/C-programming-arrays#1) <#1 (comment)> Does it make sense to make this a tiny lab asking for just array_merge and give them mergesort? This lab seems to have remained untouched for a couple of years, but I'm looking for feedback before next week. There are probably other things we could do instead of this lab, but I didn't notice this issue until now, unfortunately. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACJZWJX4RPQILHK4Z2FFZD3TND7NAVCNFSM6AAAAACG5KROTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMJQGA3TINZTGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>