Rayiner Hashem wrote:
On 27 Oct 2005 16:06:56 +0200, Immanuel Litzroth immanuell@enfocus.be wrote:
A header containing only: typedef long long unsigned int tp; generates: (defpackage "TEST" (:use #:CFFI) (:nicknames) (:export "TP"))
(in-package "TEST") (asdf:operate 'asdf:load-op 'verrazano-support) (cffi:define-foreign-type tp () 'long long unsigned int) (cl:progn)
which is nonsense to cffi. This is sbcl-0.9.6, fetter+cffi from cvs, linux.
Now, this is an interesting problem. There are a number of issues with "long long" that keep cropping up. To be pedantic, "long long" isn't a valid C++ type. This is not in and of itself a problem, because GCC-XML accepts it anyway and the only thing Vzn needs to do is have it in its type translation table (apparently, I've missed a few permutations of it, though). The bigger problem is that there is nothing sensible to map "long long" too, at least on a 32-bit system. On such a system, long long maps to a 64-bit word (a pair of 32-bit registers), and there is no way to express that in C-FFI. Anybody have any ideas?
Sounds like CFFI needs an extension. What are other FFIs such as AllegroCL and CLisp doing?
Will such a creature actually only work on a 64-bit system? If not, what do they become on 32-bit systems? Can they be treated benignly as 32-bit longs on 32-bit systems, failing only where runtime values actually exceed 32 bits? I am just hunting around for some imperfect solution that fails no more often than would using the library on a 32-but system even from a C client application.