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: "Kaz Kylheku (libffi)" <382-725-6798 at kylheku dot com>
- To: libffi-discuss at sourceware dot org
- Date: Mon, 29 May 2017 18:24:13 -0700
- Subject: Re: Also: problem with return value in ffi_call on PPC64.
- Authentication-results: sourceware.org; auth=none
- References: <3b9c322ddca2e20fa30c7eba0e5ebda2@mail.kylheku.com> <20170528192241.464e7ebe@sf>
On 28.05.2017 11:22, Sergei Trofimovich wrote:
On Sat, 27 May 2017 19:15:35 -0700
"Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> 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?
Indeed, it seems yes.
Confusingly yes. But only for integral types smaller that ffi_arg.
Thanks for your response and everyone else's.
I feverishly patched up all my code on Saturday night and got all my
test cases to pass on PPC64 with clean Valgrind, without regressing
on the little endian Intels.
My OOP-in-C framework that wraps around libffi basically absorbed this
change quite easily, with hardly much uglification. Just a proliferation
of boiler plate code.
(I never suspected it would be otherwise; but it was a question of
understanding the requirements first; having already acted hastily
on the somewhat wrong requirements already.)