[Openmcl-devel] #_ arg expansion problem

[Gary Byers]

On Fri, 9 Jul 2004 taube at uiuc.edu wrote:

> I am working with a large ffi database (4,000+ function entries) that I
> generated from Fink's GTK+2 developer package using OpenMCL's ffi tools. All the
> #_ calls expand corrently in the ffi EXCEPT one entry that
> %external-call-expander claims requires two arguments but actually only requires
> one according to the .ffi and .h source files. The problem entry is for the glib
> function "g_scanner_cur_value". Oddly enough, there are several other such
> "g_scanner_" functions with identical arg declarations that do resolve correctly
> in the ffi.
>
> Here is the C declaration of g_scanner_cur_value :
>
> ------ in gscanner.h:
>   GTokenValue g_scanner_cur_value (GScanner *scanner);
>
> And here is the entry in the "gtk.ffi" file that I created by doing "h-to-ffi
> `pkg-config --cflags gtk+-2.0`" :
>
> ------ in gtk.ffi:
>   (function ("/sw/include/glib-2.0/glib/gscanner.h" 215)
>    "g_scanner_cur_value"
>    (function
>     ((pointer (typedef "GScanner")) )
>     (typedef "GTokenValue")) (extern))
>

What does the type definition for GTokenValue look like (in the .ffi file) ?

I have a hunch that it's a structure of some sort ...

C functions that "return" structures don't really return them in the
same sense that they return scalar numeric values or pointers.  Under
the hood, they actually take a (caller-allocated) pointer to a
structure of the appropriate type as a first argument, and they
"return" the structure by storing into the fields that this pointer
points to.

The C idiom

	aGTokenValue = g_scanner_cur_value(scanner_ptr);

is actually implemented as:

	g_scanner_cur_value(&aGTokenValue, scanner_ptr);

Assignment in C (via =) understands this structure return convention
and provide syntactic sugar for it. This doesn't fit too well into
lisp (where functions return values ...), and the FFI translator
makes the behind-the-scenes activity explicit.  (Randall Beers'
SLET macro in the Cocoa bridge tries to provide some lispier
syntactic sugar for structure-returning functions, which are
apparently much more common in Cocoa than in GTK+.)

On Darwin, a C function that "returns a structure" follows this
convention unless the structure would fit in a machine register
(is at most 32 bits wide), in which case the structure is returned
as a scalar value (a somewhat strange-looking integer.)  I don't
believe that the FFI translator has ever handled this (rare)
exception correctly (and I suppose that the only way to handle
this "correctly" is to make the return type :UNSIGNED-LONG and
leave the interpretation of that integer as a structure up to
the caller.)

So, whether this translation is correct or not depends on how big
a GTokenValue is ...