lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Jun 18, 2014 2:38 PM, "Andrew Starks" <> 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.