This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Also: problem with return value in ffi_call on PPC64.
- From: "Kaz Kylheku (libffi)" <382-725-6798 at kylheku dot com>
- To: libffi-discuss at sourceware dot org
- Date: Sat, 27 May 2017 18:36:21 -0700
- Subject: Also: problem with return value in ffi_call on PPC64.
- Authentication-results: sourceware.org; auth=none
Hi all,
It turns out that return values from foreign calls are also not working
in the way I expect.
For instance, the int return value of dup comes out as zero if a file
descriptor is returned.
The -1 value emerges properly due to sign extension:
1> (with-dyn-lib nil (deffi dup-fd "dup" int (int)))
#:lib-0175
2> (dup-fd 0)
0
3> (dup-fd 4)
-1
4> (dup-fd 3)
0
5> (dup-fd 4)
0
6> (dup-fd 5)
0
7> (dup-fd 7)
-1
8> (dup-fd 7)
-1
Are users supposed to assume that the return value has been widened to a
register-wide (8 byte) value regardless of its declared FFI type?
Why doesn't that convention apply to the arguments, then? When dup is
being called above, the int value is being written at the bottom of the
argument buffer, not displaced by four bytes.