[gambit-list] Converting uint32 to scheme object

Marc Feeley feeley at iro.umontreal.ca
Wed Jan 6 23:44:51 EST 2016


You are arguing that you can’t do much better than Lua’s FFI if you don’t have a compiler (code generator?) to generate the glue code.  That seems to be an artificial constraint, because it is possible to implement such a code generator!  My point is that, for the user of the system, it is better when the process of checking types, number of parameters, heap overflow conditions, exception raising, etc are automated.  When the process is not automated, these things are not typically done by the user (or are done incorrectly or not completely) because it is tedious and error prone to check all conditions.

Marc

> On Jan 6, 2016, at 11:25 PM, Hendrik Boom <hendrik at topoi.pooq.com> wrote:
> 
> On Wed, Jan 06, 2016 at 11:00:26PM -0500, Marc Feeley wrote:
>> I can see a few problems with the glue code you wrote to interface your C function to Lua:
>> 
>> - it isn’t checking that the number of parameters received by the function is correct
>> - it isn’t checking that the first parameter is a pointer of type TIFF*
>> - it isn’t checking that the first parameter is not NULL
>> - it doesn’t appear to do the right thing when val is a uint32 with the upper bit set (I suspect it will return a negative integer)
>> - if there is a type error (say the second parameter is not an integer), will there be a precise error message or exception indicating that the second parameter was not of the right type? can the exception be caught in Lua?
>> - I suspect that lua_pushinteger may allocate memory (for a bignum or flonum?), so what happens if this allocation causes the heap to overflow? can this be caught in Lua?
>> 
>> In this particular example, Gambit’s glue code is not much longer than the one for Lua, but it doesn’t suffer from these issues.  For a typical function with simple types for parameters and result, Gambit’s FFI does not require any glue code.
> 
> Let me guess that your FFI accomplishes its goals by generating and 
> compiling C code.  You can do a lot that way.
> 
> I believe that Lua was originally an interpreter written in portable C, 
> and there was no mechanism in C to call a statically unknown function 
> with a statically unknown number of parameters of statically unknown type. 
> C is not the only language with this problem, and the Lua C interface is 
> about as good as you can get under this constraint.
> 
> I don't know if there is such a mechanism now; I've heard that there are 
> such gcc extensions, but that's not as portable as one might like.
> 
>> 
>> So as you can probably tell, I’m more enclined to qualify Lua’s FFI as “simple” and not “brilliant”… :-)
> 
> A simplicity born of necessity.
> 
> Gambit had entirely different constraints.  Didn't it originate as a 
> compiler from Scheme to C?
> 
> -- hendrik
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list




More information about the Gambit-list mailing list