Overflow checks

Ahh, right - that makes a lot more sense!

Thanks for that - in _jswrap_interface_setTimeoutOrInterval I think there isn't a huge issue because jsvObjectSetChild is null-safe, although the jsvObjectSetChildAndUnLock that it calls could still 'lose' some locks. I'll add a guard in anyway.

jsvObjectSetChildAndUnLock is a really good spot - thanks! I've just pushed a fix for that.

It's definitely good practice to check when allocating something like an object but I wouldn't worry about trying to clean up after yourself in the library. When you do 'SetChildAndUnLock(.... jsvNew...)` then memory errors really don't matter at all.

Espruino should continue working just fine after an out of memory error - and actually the Linux build does have a 'memtest' where it'll just run the tests time after time, slowly decreasing memory so that it can see if anything breaks badly when out of memory happens at different times.

If a lock is 'leaked' it's not the end of the world. It basically just means that var can't be garbage collected, so it might result in a memory leak - but in many cases it probably won't even be noticed.