Re: Mike Pall's standalone FFI: a dream?

[Justin Cormack <justin@...>]

On Thu, 2011-05-12 at 11:09 +0200, steve donovan wrote:
> On Thu, May 12, 2011 at 11:01 AM, KHMan <keinhong@gmail.com> wrote:
> > Eh, my memory cells is a failure, a C preprocessor in Lua is probably more
> > like a 40KB stripped binary chunk. But it's under 20KB without the #if*
> > conditional syntax and expression parsing. There is quite a lot to
> > implement...
> 
> Oh yes, that's the complicated bit!
> 
> Although does it make sense to expect a Lua FFI package to read
> implementation C header files?  They are clunky and often depend on
> lots of little bits. Much better to have a tool to massage them and
> extract exactly what one wants, and include that. Such a tool could
> start out by using the standalone C preprocessor as a first step.
> 
> Then (for instance) the target system only needs foo, not foo-dev

There is a tiny advantage in reading the actual header files at runtime,
if interfacing with nasty packages that expose an ABI that varies a lot
depending on how it is installed or built, but most sane code exposes a
reasonably sane ABI that can be used with sanitised headers (like the
ones you need to use for LuaJIT now), maybe with some conditionals. I
think it is easy to write C code for using with FFI, it just means
hiding the implementation details behind void* pointers with a heap
allocator, or using basic machine types. There is some code that has a
messy API/ABI (openssl I am looking at you), but maybe it is easier to
use a C wrapper or a different library in that case.

Justin