[gambit-list] Converting uint32 to scheme object

Hendrik Boom hendrik at topoi.pooq.com
Wed Jan 6 20:48:37 EST 2016


On Wed, Jan 06, 2016 at 11:59:00PM +0100, Alex Queiroz wrote:
> Hi Marc,
> 
> On 6 January 2016 at 16:10, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> > Could you show the actual code required for Lua?  Is it able to catch heap overflows in Lua code?  When there is a conversion error, does the error message indicate which parameter is causing the problem?  How must the glue code be written to avoid space leaks and dangling references?  Does it support bignums?
> >
> > The Gambit FFI was designed to interface to C libraries directly (without having to write glue code).  Is this possible with Lua’s FFI?
> >
> 
> The Lua C API always require glue functions. In fact, all C functions
> callable by the VM have the same fixed prototype. The same code would
> be:
> 
> ```
> static int uint32_tag(lua_State *L)
> {
>    TIFF *tiff = (TIFF*)lua_touserdata(L, 1);
>    ttag_t tag = (ttag_t)lua_tointeger(L, 2);
> 
>    uint32 val;
>    if(TIFFGetField(tiff, tag, &val) == 1)
>    {
>       lua_pushinteger(L, val);
>    }
>    else
>    {
>       lua_pushnil(L);
>    }
> 
>    return 1;
> }
> ```
> The Lua API is based around a stack where arguments and return values
> are passed back and forth. The `lua_to*` and `lua_push*` functions
> take care of casting, boxing and memory management. Although the FFI
> code may be a little verbose for simpler functions, I never found a
> situation where I had to work around something. There are also check
> functions that help checking the type of arguments are throwing
> exceptions if the types are wrong.

I once wrote a prototype for an int0-memory low-level code generator 
that was intended to be used in an interpreter.  I ended up using tha 
same kind of stack API.  It all seemed kind of FORTH-like.

-- hendrik



More information about the Gambit-list mailing list