Re: Building luaffifb with MSVC

[Dibyendu Majumdar <mobile@...>]

On 13 February 2018 at 18:47, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> Steven Johnson wrote:
>
>>>> I seem to recall the C namespace just getting absorbed into another one
>>>> rather than being outright missing. This sounds like it might be a
>>>> simple problem (wrong table index? maybe an off-by-one caused by some
>>>> platform defines?) but I ended up getting distracted before looking
>>>> into it.
>
> I have made some progress with this.
>
> First problem appears to be that we need an additional MSVC compiler
> define - as implemented in LuaJIT
> (https://github.com/LuaJIT/LuaJIT/commit/02b4b1e55633c36f370058e7601c77ba561e2c8a).
> This has solved the issue of finding ffi.C.sprintf).
>
> Secondly, on Windows a symbol loaded by ffi.load() does not go into
> global namespace, whereas this works on Posix environment, but only
> supposed to happen if a second argument is supplied to ffi.load - see
> here (http://luajit.org/ext_ffi_api.html). There is possibly a bug in
> luaffifb where symbols are perhaps being loaded into global namespace
> when they should not be. This explains why on Windows you need to
> access the library module in the dlls table to access functions in the
> libtest module. Btw this appears to be a regression in luaffifb - i.e.
> original code does not attempt to access symbols in libtest using
> ffi.C.
>
> Next issue is that on Windows <complex.h> is not ISO C compliant - and
> the check for this was incorrect (actually also a regression from
> luaffi where it is correct).
>
> Fourth issue is the use of %p in some tests - unfortunately there is
> no defined output format for %p, and on Windows this is different.
> After fixing this I found an issue (possibly a bug) where float
> arguments are not being passed correctly ... to be investigated.
>

Looks like there was a bug in luaffi when passing parameters to
functions on the stack on x86-64 platform. I have not found definitive
documentation clarifying this (if anyone can provide a reference that
would be very helpful) but it seems that stack arguments must be at 8
byte boundaries. It also appears that the Facebook fork applied a
partial fix (covering 1 of out 4 scenarios) - so the bug is present in
luaffifb as well. Anyway I have applied a fix and now the tests pass
on Windows. I would have expected the impacted tests to fail on all
X86-64 platforms so not sure yet why they were passing on Mac OSX.

As above is quite a serious bug, I need to beef up the tests in this
module to ensure that as many scenarios are tested as possible.

Regards
Dibyendu