I was very hesitant to see if I could even return a list from a procedure.

By some miracle, that also works too! And also note the local scoping of `i` in that `for` loop! 😲

It wasn't a problem with that function itself. What was the problem is that my code was littered with calls to `catto_appendCharToString`, and I was throwing away its return value in each case.

You'll notice in the function declaration that I return the value of `CATTO_REALLOC` — AKA `realloc`.

Oh dear.

At first, I thought it would be an issue with my memory allocator again — it could possibly be returning the wrong memory addresses or overwriting areas of memory it shouldn't.

Nope, it turns out it's a problem with my use of this function here...

I clicked on 'run' multiple times. Looks like atto didn't work...

(Each line in this console output should be exactly the same.)

Why on Earth is it printing `yoyo`???

Back to the drawing board then. 🫤

I wanted to see how well atto could cope with returning strings from procedures.

(For context, to return something from a procedure, you have to store the return value into a parameter variable, which is basically given by reference.)

So I wrote a simple program to return the string `"yo"` with the value of `n` appended to it.

If you call `free` multiple times for a contiguous set of memory blocks, then the next call to `malloc` will attempt to stitch together those individual free blocks into a larger free block before attempting allocation.

Here's a hastily-drawn diagram to show you what I mean.

For a bit of background, I've been trying to get a web version of my atto programming language working correctly with all sorts of advanced features, like procedures with scoped variables.

It works by running catto (my C implementation of atto) in a WebAssembly module, which is then wrapped with JavaScript.

(Sounds a bit ridiculous given that the original atto was written in JavaScript, but I want to ensure that the behaviour of atto is consistent across platforms.)