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