[cffi-devel] Re: [fetter-devel] wrong code generated
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. -- Kenny Why Lisp? http://wiki.alu.org/RtL_Highlight_Film "I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950
Sounds like CFFI needs an extension. What are other FFIs such as AllegroCL and CLisp doing?
AllegroCL appears to have a long-long type that does the right thing.
Will such a creature actually only work on a 64-bit system?
On a 64-bit system, "long long" can usually be mapped to the system's "long" type (which, in most OSs, is 64-bits). On Win64, the "long" type is still 32-bits, but from C-FFI's point of view, its still fairly simple to map it to an _int64 or whatever, since it'll still be a single machine word.
If not, what do they become on 32-bit systems?
They become a pair of words, stored in a pair of registers. For example, it'll be stored in EAX:EDX, then when it needs to be written to memory, two MOVDs will be issued, one for each register.
Can they be treated benignly as 32-bit longs on 32-bit systems, failing only where runtime values actually exceed 32 bits?
It depends on the architecture, but at least on x86-32, the fact that arguments are passed on the stack will cause the FFI to have the wrong offsets for every parameter after the "long long".
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.
The C client apps won't fail, simply because the compiler understands that "long longs" have to be treated specially. There are some hacks that could be done (transforming a single argument of type long long to a pair of arguments of type long), but they still can't handle return values properly (since there is no way to tell the FFI that a value is returned in two registers, not one). That said, I wonder if its worth more than just failing gracefully in this case. "Long long" is new to C99. Does that much code use it?
-- Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it." Elwood P. Dowd, "Harvey", 1950
participants (3)
-
Immanuel Litzroth -
Kenny Tilton -
Rayiner Hashem