Two bugs in unix64.S

[Armin Rigo <arigo at tunes dot org>]

Hi all,

I found two issues in src/x86/unix64.S (using some custom memory
access debugger included in PyPy, a Python implementation in Python).

The main issue is that the ffi_call_unix64() function interprets its
raddr argument differently than, say, ffi_call_win32() in win32.S.  In
ffi_call_win32() it is supposed to be a pointer to exactly as much
memory as needed for the return type of the function, which I suppose
is the intended semantics.  However in ffi_call_unix64() we always
writes 8 bytes into *raddr, even when the return type is declared as
FFI_TYPE_SINT32 or FFI_TYPE_SINT8.  The second, smaller, issue is that
the assembler source code is missing "ret" at the end of the cases
.Lst_uint16 and .Lst_uint32.

In the "common" use case, the two issues don't cause any difference,
because raddr will be typically obtained by malloc(), which reserves
anyway at least 8 bytes; and if the user only expect to read 2 or 4
bytes out of it then the missing "ret" don't cause any problem either.

I'm still mentioning this because there are other cases where it can
cause random memory corruption, e.g. if raddr is the address of a
local variable.


Armin Rigo