This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: Also: problem with return value in ffi_call on PPC64.
- From: Andrew Haley <aph at redhat dot com>
- To: libffi-discuss at sourceware dot org
- Date: Tue, 30 May 2017 09:27:44 +0100
- Subject: Re: Also: problem with return value in ffi_call on PPC64.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=aph at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E7B608123F
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E7B608123F
- References: <a1bda55849470c990b5c319c92351cf7@mail.kylheku.com>
On 28/05/17 02:36, Kaz Kylheku (libffi) wrote:
> 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?
Yes.
> 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.
It's more of a historical accident than anything planned. But it's not
important enough to break backwards compatibility.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671