From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37568 invoked by alias); 28 May 2017 04:13:57 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 37365 invoked by uid 89); 28 May 2017 04:13:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=enclosure, HTo:U*libffi-discuss, H*r:4.72, H*F:D*kylheku.com X-HELO: smtp-out-so.shaw.ca Received: from smtp-out-so.shaw.ca (HELO smtp-out-so.shaw.ca) (64.59.136.139) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 28 May 2017 04:13:42 +0000 Received: from kylheku.com ([70.79.163.252]) by shaw.ca with SMTP id EpaJduVVPeQWUEpaKdtN9E; Sat, 27 May 2017 22:13:44 -0600 X-Authority-Analysis: v=2.2 cv=UpATD64B c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=tJ8p9aeEuA8A:10 a=zBPOc9SkG02dxPfBsoIA:9 a=QEXdDO2ut3YA:10 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from ) id 1dEpaH-0003rc-GR for libffi-discuss@sourceware.org; Sat, 27 May 2017 21:13:41 -0700 To: libffi-discuss@sourceware.org Subject: Re: Help: correct way to handle struct return values. X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Sun, 28 May 2017 04:13:00 -0000 From: Kaz Kylheku In-Reply-To: References: Message-ID: <074a6bc9c4cd327f1a3aa07877c36e5e@mail.kylheku.com> X-Sender: kaz@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfBe98/LOiJ5zpFG8/OY4dTwu4T8IBzfgOB8P9rLajn7B7qHFNfdOlEcweOIAOHYFaEtVdoiqgKS9kve/36laPbn7PHtxXRyyWJI7f1ruYc1WEkafdo9w 3MQqPZAHg4Rt49F8ccH9QgeNobBDkyHIXF65mHX42fefmdc/B7x5OHqt+0gXPNNapwwfO+Pqj+vspw== X-SW-Source: 2017/txt/msg00008.txt.bz2 On 27.05.2017 20:14, Kaz Kylheku wrote: > Hi all, >=20 > In the current texinfo doc, the callback stub does this to > return a value of type int: >=20 > /* 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 =3D fputs(*(char **)args[0], (FILE *)stream); > } >=20 > 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: >=20 > 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 =3D (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.