[fetter-devel] wrong code generated

[Kenny Tilton]

Rayiner Hashem wrote:

>On 27 Oct 2005 16:06:56 +0200, Immanuel Litzroth <immanuell at 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