shouldn't "lua_register" allow specifying names in the Lua-to-C bindings, so that positional (integer indexed) parameters would have a name (and possibly a formal type description) if parameters C function has static datatypes (not varargs), and some datatype conversions could occur when needed (e.g. converting a Lua "number" to a C "short", or "float", or "double", or a Lua "string" to some of the string datatypes supported in C such as "char*" where Lua would allocate a copy of the string, possibly also supported charsets conversion to UTF-8, or UTF-16 or a windows OEM charset, possibly lossy with fallbacks, or could authorize to pass the internal buffer if the C function uses it as a "const char*", i.e. with a supposedly readonly buffer, and avoid the extra cost to the memory allocator and complications to the garbage collector, or could use alloca() to allocate writable short strings in the "C" call stack itself).
The interface between Lua and C should offer better flexibility for the bindings, with additional performance benefits (but possibly security problems to solve). If we compare to what is sone in Java, JNI passes all strings using copies to temporary buffers allocated externally, the problem being that the binding must be also flexible enough to know when to free that buffer, if the C function wants to keep that buffer internally and does not reallocate its own local copy out of the memory pool managed by the JVM: this is important if such buffers are used to perform asynchronous requests that will still run when the "C" function returns or that will be reused later when an event handler will need these buffers, possibly in another thread, or in another process via some shared memory like a memory-mapped file or some RPC/LPC mechanism of the OS; it's hard to cleanly separate the memory pools and isolate the sandboxes to secure them: binding can be quite complex, the alternative being to define a very restrictive ABI restricting the datatypes we can pass to C and restricting as well their lifecycle.)
