From: Kaz Kylheku <kaz@kylheku.com>
To: libffi-discuss@sourceware.org
Subject: Re: Help: correct way to handle struct return values.
Date: Sun, 28 May 2017 04:13:00 -0000 [thread overview]
Message-ID: <074a6bc9c4cd327f1a3aa07877c36e5e@mail.kylheku.com> (raw)
In-Reply-To: <ec6e2212f16df6ba23cc4c4d1fc78cfd@mail.kylheku.com>
On 27.05.2017 20:14, Kaz Kylheku wrote:
> Hi all,
>
> In the current texinfo doc, the callback stub does this to
> return a value of type int:
>
> /* Acts like puts with the file given at time of enclosure. */
> void puts_binding(ffi_cif *cif, void *ret, void* args[],
> void *stream)
> {
> *(ffi_arg *)ret = fputs(*(char **)args[0], (FILE *)stream);
> }
>
> Can someone show what the code would look like for a function
> that returns the following type, and work everywhere: all
> supported platforms, big or little endian:
>
> struct little { char a, b };
This corresponds to libffi.call/struct5.c
Everything I'm seeing in the test suite seems like structs are handled
in the straighforward way in both ffi_call and closures. But
in this small struct test case there is this comment:
/* This is a hack to get a properly aligned result buffer */
test_structure_5 *ts5_result =
(test_structure_5 *) malloc (sizeof(test_structure_5));
What are the alignment requirements here; must the small
structure have the same alignment as ffi_arg?
And why so, if its size is smaller? If this has to be,
say, 8 bytes aligned, doesn't it mean something will be writing
an 8 byte data unit into it? In that case, shouldn't
the malloc request be padded up to 8 so there is no overrun?
I am not concerned about the alignment because I'm using alloca
for the return value buffer given to ffi_call.
I am worried though about the size. alloca(2) could give me an
8 byte aligned pointer which is only two byte away from the next
object on the stack; if something writes 8 bytes there, that is
very bad.
prev parent reply other threads:[~2017-05-28 4:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-28 3:14 Kaz Kylheku
2017-05-28 4:13 ` Kaz Kylheku [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=074a6bc9c4cd327f1a3aa07877c36e5e@mail.kylheku.com \
--to=kaz@kylheku.com \
--cc=libffi-discuss@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).