[Openmcl-devel] Re: Helmut Eller's ffigen changes

[rm at fabula.de]

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
> REFERENCE-FFI-TYPE.)
> 
> 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


   RalfD
>