[Openmcl-devel] Re: Helmut Eller's ffigen changes
rm at fabula.de
rm at fabula.de
Thu Dec 9 12:18:05 UTC 2004
On Wed, Dec 08, 2004 at 04:28:05PM -0700, Gary Byers wrote:
> > I wasn't able to find any reference to builtin-va-list so far, so maybe someone
> > on this list can enlighten me?
> The ffi_primitive_names table is supposed to explain how to map from
> (the printed representation of) a GCC builtin-type to some lispy symbol
> that'll be written to the .ffi file. I think that there's actuallly
> a way to get GCC to spit out the left-hand-side of this table; if GCC
> is AltiVec-aware (as it is on Darwin), there'll be more/different
> built-in types. (Apparently, __int128_t is now a standard builtin
> GCC type. Some of these things could - and may have been in the past -
> defined with typedef, but there are apparently advantages to having
> the compiler have some intrinsic awareness of them.)
So, currently OpenMCL just ignores/can't handle 128-bit integers?
(not that it would matter to me).
> There's a similar table in "ccl:library;parse-ffi.lisp", which maps
> the entries on the right-hand-side of the table above (interned as
> keywords) to type names in OpenMCL's FFI. (The "table" is actually
> an ECASE that we're presumably not satisfying, in the functon
> I think that adding a (:BUILTIN-VA-LIST '(:primitive (* :void))) clause is
> probably close enough
Hmm, i tried this but OML complains:
? (parse-standard-ffi-files :gtk2)
#P"/usr/lib/openmcl/headers/gtk2/C/gtk2-wrapper.ffi" ... NIL
> Error in process listener(2): value :PRIMITIVE is not of the expected type (MEMBER * :SIGNED :UNSIGNED).
> While executing: ENCODE-FFI-TYPE
> Type :POP to abort.
Type :? for other options.
1 > :pop
I substituted your suggestion with '(:BUILTIN-VA-LIST '(* :void))' which at
least seems to OMCL to parse the .ffi file.
> (there probably isn't too much interesting stuff
> you can do with a C varargs "list" from the lisp side, and treating it
> as "void *" is probably reasonable.)
Hmm, _some_ callback-using frameworks do use varargs a lot.
> (It -might- also be reasonable to change the ECASE to a CASE and
> handle anything unknown as "void *".)
Thank's for all the help
More information about the Openmcl-devel