 |
lua-l archive |
|
|
||
|
On Jun 18, 2014 2:38 PM, "Andrew Starks" <andrew.starks@trms.com> wrote:
> I wanted to know if others were writing the "core" layer so that all of the function arguments and return values matched, whenever possible, with the idea being that *any* inconsistency would be a burden. For example, accepting "0" from the C function, when the Lua equivalent would return something "false-y"
I think there's an important characteristic of the wrapped stack: can Lua-side users of this interface crash out the runtime, or otherwise cause undefined behavior, in the sense of C?
I don't mean this to be absolute. For many bindings the answer is "of course Lua code can crash C" because not much C code is hardened. There are degrees, and I think a reasonable goal is to have a program you can set a breakpoint in, and not have scribbled all over memory before the debugger hits it.
* Pointer class. If my Lua code gives you an inappropriate pointer (like a sockaddr_in6 instead of a sockaddr_in), do I get a diagnostic?
This is one place where staying in C can help.
* Can I overrun a string/array accidentally?
Range errors in general, but particularly where integers denote resources like file descriptors. const-correctness too.
* Mismatch of object lifecycle problems: Double-free, use-after-free, leak.
A particularly nasty one is child objects. Creating Lua-side proxies for, say, subwidgets is painful if the containing widget frees C-side children on destruction. There was no straightforward way to solve this in Lua 4.0 FLTK; elsewhere, allocator callbacks were sufficient to turn remaining proxies into tombstones.
* Blowing out the execution environment in other ways. If you're doing cooperative multitasking, accidentally calling a blocking function is no fun.
That one is pretty obvious from the stack dump. But violation of nesting/context requirements can hurt too.
Anyway, the good news is that you can often create safer and idiomatic Lua interface wrappers to low-level C-style Lua interfaces. It's what you have to do in LuaJIT ffi, and what I usually do, since my first goal in most C environments is "get the hell out of C". But sometimes libraries simply do not have functionality exposed to match a dynamic language.
Jay