Investigate breaking points for Lua

[mchlmmc]

Right now, my attention has been put into adding features to CirnOS to give the user enough power to complete full projects using this operating system.

I have not tested to see how easy it is to break Lua, so it is very possible that there are ways for perfect looking Lua code to run improperly.

Look for the following things:

• Library functions that do not work
• Methods of crashing the system
• Methods of causing stack overflows (related)
• Standard Lua features that do not work as expected

[tilkinsc]

I fixed stack overflows in one function in the pull request #11 Just gotta remember to lua_checkstack(lua_State* L, int nelem);

By library functions I assume you mean anything given by luaL_openlibs(L); I displayed them out in my pull reqest #11 . I am guessing package isn't set up properly aka package.cpath and package.path. ffi will not work because we haven't established so files that the system can use? idrk...

We need to sanitize input for functions like delay so we don't delay(0), as it would probably be a bug in the code. If you really didn't want a delay, don't put it in there or encapsulate it with an if statement or ternary.

[mchlmmc]

It's true that I have not yet tested FFI, that is a must that should come very soon. The blocking of 0 delays goes with the CirnOS philosophy of having only one way to do everything, I don't want people using that as a NOP function etc.

Will do that next.