One of the approaches to freeing memory is to call free right after the last usage of a pointer (in our case it's the loop which calls inline_stack_push(sv_2mortal(newSViv(c_array[i])));) and set it to NULL afterwards.

Setting a pointer to NULL serves double purpose:

1. Checking for NULL is very easy, checking if non-NULL pointer is valid is very complex at best
2. If you defensively call free(c_array) in another part of the program, free(NULL) would be safe on modern libcs, while free of a freed pointer causes memory corruption

Thank you very much AnonyMonk!

I especially appreciated the fact you used the term "our" in your reply, as it shows that even Anonymous Monk cares and has interest ;)

I'll pull this back out over the weekend sometime and play around with it and run things against valgrind.

Your feedback is appreciated in my curve of learning. I'll update the OP after I've played around.

I'll pull this back out over the weekend sometime and play around with it and run things against valgrind.

I'm not sure about properly written libperl applications (i.e. ones creating PerlInterpreter objects and not forgetting to call perl_destruct(my_perl); perl_free(my_perl); PERL_SYS_TERM(); afterwards), but perl itself is known to show leaks when checked by valgrind. As in,

$ valgrind perl -e1 2>&1 | grep definitely
==12501==    definitely lost: 7,075 bytes in 15 blocks
[download]

Part of the reason for that might be to speed up termination: why bother calling free() if the process is going to die right now and the OS will pick up its resources anyway? But there are other possible reasons for valgrind to report a memory leak.