FFI problem: too many arguments

nicolas cellier ncellier at ifrance.com
Thu Feb 16 21:42:11 UTC 2006


Le Jeudi 16 Février 2006 20:28, vous avez écrit :
> You should have a look at ByteSurgeon in Squeak :)
>
> Stef

Thanks, I'll have a look at it. Seems good to try extensions of Smalltalk.

Now, it seems that the too-many-arguments-problem has one solution:

IDENTIFICATION OF EXISTING PRIMITIVE:
-------------------------------------------------

It appear that function FFIPlugin>>#primitiveCalloutWithArgs do exactly what
 i require:
it will invoke the external method with an arbitrary number of arguments
packed into an Array (in order to have a single method argument).

Just have to discover the hack how to invoke it, without creating the
ExternalMethod by hand... (I do not want to paraphrase Parser <cdecl:...>
interpretation).

PROPOSED SOLUTION (modification of compiler)
----------------------------

I noticed that #primitiveCallout is already a hack in the compiler (primitive
number 120 is hard coded in the Parser).

It is simple to add another hack that would still generate the
ExternalFunction as first literal but send #invokeWithArguments: instead of
primitive 120 in case the arguments size do not match... (in
MethodNode>>#generate: ).

By now, when arguments size do not match the ExternalMethod argTypes size +
 1, the primitive simply fail (cf. FFIPlugin>>#primitiveCallout).
We do not get a warning at compile time... That's bad.

Better behaviour would be to signal size mismatch at parser level, then if
number of method arguments is 1, signal the user that this may work if the
arguments is an array, propose to proceed or to abort.

The hack is not beautiful, but neither is actual code.
This would solve my problems and possible future problems of guys wishing to
use FFI.

REQUEST TO PROCEED WITH IMPLEMENTATION
------------------------------------------------------------

I did not check the 3.9 image. Is there work in progress in such area ?
If not, I can proceed unless anyone has objections ?





More information about the Squeak-dev mailing list