FFI questions

Andreas Raab andreas.raab at gmx.de
Fri Sep 5 01:45:00 UTC 2003


Hi,

> I'm running into some problems with FFI.  This is the method 
> I am using:
> 
> cgCreateProgram: ctx with: programtype with: program with: 
> profile with: entry with: args
> 	"This method was automatically generated."
> 	"CGprogram cgCreateProgram(CGcontext ctx, CGenum 
> program_type, const char *program, CGprofile profile, const 
> char *entry, const char **args);"
> 	<cdecl: ulong 'cgCreateProgram' (ulong ulong byte* 
> ulong byte* byte** ) module: 'Cg'>
                  ^^
And this is the problem. The FFI can't coerce arrays of pointers
automatically, so using "foo **" in any way is simply invalid.

> If I get ahold of the resulting CompiledMethod and look at the first
> literal, it is an ExternalLibraryFunction corresponding to the FFI
> spec.  One thing that is odd is the contents of the 
> 'argTypes' variable
> of the ELFunc: #(ulong ulong ulong byte* ulong byte* byte void).  Why 
> might the 'void' be there?

Looks like a parser error which should be fixed. "**" needs to raise an
error unless we fix the ffi plugin to do the right coercion, which ... err
... seems hard.

> This brings me to my next question(s):  
> - Will FFI know how to coerce a String to a 'byte*'?

Yes. The difference between "byte*" and "char*" is that "char*" will force
the argument (a String) to be converted into a zero-terminated C string. For
example

Stdio>>puts: aString
	<cdecl: void 'puts' (char*)>

will allow you to use 

	Stdio new puts: 'Hello World'.

whereas using 'byte*' in the above will print out half of Squeak's object
memory.

> - What the heck do I do for 'byte**'?  
>   (The C function expects an array of null-terminated strings)

You need to assemble the arguments manually. Bert had a nice example for
this some time back (it was some socket related stuff) you may want to
google for it.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list