Dynamic languages and C

I’ve been tinkering about an idea for a while. It’s fairly easy given an API specification to write glue code so that you can call from your favourite dynamic language into C. Swig is a program that given an API will generate all the glue code you need to make that library available in a variety of langauges (python, perl, java, ruby, tcl, guile and heaps of others). The problem is you have to sit down and write this glue yourself. But do you? When compiled with debugging information C libraries all contain information about the types of all the symbols in the file. C++ is even easier, the name mangling standards provide all the type information you could ever want.

So, every so often I tinker around with writing a python library that will use pythons import hooks to let you import arbitary C libraries and call through transparently into the functions contained within. There are however several stumbling blocks.

First is that calling an arbitary C function is difficult. Oh sure dlsym(3) can return a pointer to whatever symbol you can care to name, but you still need a way of passing it arbitary parameters. gcc has __builtin_apply() but that seems uh quirky at best, and isn’t really designed with this in mind. Then, after that I’ve got to write something to parse .so files and read the stabs debugging information. Now I’m planning on doing this in python calling through to libbfd (which I can manually provide the symbol table and type information for).

Anyway, just my thoughts. Thought I should document them somewhere as I don’t think I’ve mentioned them here anywhere.

2 Responses to “Dynamic languages and C”

  1. Aristotle Says:

    Is the debugging information rich enough so you can know what do to when a function wants or returns some_struct_t*?

    And what if it’s void*?

  2. Ken Hirsch Says:

    No portable way. Here’s a library which supports the most popular architectures:
    http://www.haible.de/bruno/packages-ffcall-README.html