[cinvoke-dev] Lua C/Invoke 64 bit return values

[Dwight Schauer]

I'm using C/Invoke Lua and it is working out fairly well.

I'm running into problems with 64 bit integers though on 32 bit
platforms. It is not a C problem, as the underlying C code handles the
64 bit integers without any problem.

I'm doing my testing on Linux x86_64 and Linux x86_32.

I patched Lua to handle 64 integers cleanly, and that works fine on
both 32 and 64 bit.
http://luaforge.net/projects/lnum/

I had to patch C/Invoke Lua as it was mangling 64 integers by using
"number" routines rather than Lua "integer" routines.
I have a crude sed patch for that here:
http://aur.archlinux.org/packages/cinvoke-lua/cinvoke-lua/PKGBUILD

I need to do a proper patch that uses "#ifdef LNUM_INT64" and
conditionally compiles the appropriate code.

On an unrelated note, I also patched _clibrary_get_function to allow
an address to be passed in with @ as the first character of the
symbol.
http://aur.archlinux.org/packages/cinvoke-lua/cinvoke-lua/_clibrary_get_function.patch

On 64 bit I can use C/Invoke Lua to pass 64 bit integers into C
functions, and have the C functions return 64 bit integers properly
without mangling any of the bits.

On 32 I can pass 64 bit integers without any problem from to C via
C/Invoke, and they are not mangled.

The problem on 32 bit is that I can't return 64 integers from C
functions to Lua properly, only the lower 32 bits are returned.

I've tried both Clonglong and Cint64, the results are the same.

Any advice?

I'm trying to keep all my code the same as much as possible on 32 and
64 bit platforms. With C I can do this, and with the patch for Lua I
can do this, but now I'm running into problems with C/Invoke as far as
this is concerned.

I looked into this a bit in cinvoke_lua.c, but have not found the problem yet.
At the top of unmarshall_retval I put in a printf and at that point 64
bit returns are always already truncated (upper is all Fs).

I also put a printf in _function_call right before the
cinv_function_invoke call and the return type is correct, 4 indicating
CINV_T_EXTRALONG. I looked at the all relevant cinvoke code for
processing the return value and it all seems reasonable to me at a
cursory glance.

--DAS