From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82057 invoked by alias); 28 May 2017 02:16:18 -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 81549 invoked by uid 89); 28 May 2017 02:15:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:64.59.134.12, Hx-spam-relays-external:64.59.134.12, idiot, HTo:U*libffi-discuss X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 28 May 2017 02:15:37 +0000 Received: from kylheku.com ([70.79.163.252]) by shaw.ca with SMTP id Enk0d2Tf2M9gtEnk1dQJob; Sat, 27 May 2017 20:15:37 -0600 X-Authority-Analysis: v=2.2 cv=a+JAzQaF c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=tJ8p9aeEuA8A:10 a=xGWB3w-mHHkA:10 a=gs0CaNqOLcfA9wLHPW0A:9 a=QEXdDO2ut3YA:10 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from <382-725-6798@kylheku.com>) id 1dEnjz-0001H5-4i for libffi-discuss@sourceware.org; Sat, 27 May 2017 19:15:35 -0700 To: libffi-discuss@sourceware.org Subject: Re: Also: problem with return value in =?UTF-8?Q?ffi=5Fcall=20on?= =?UTF-8?Q?=20PPC=36=34=2E?= 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 02:16:00 -0000 From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Message-ID: <3b9c322ddca2e20fa30c7eba0e5ebda2@mail.kylheku.com> X-Sender: 382-725-6798@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfPiXPauv9tTEX4afa2qjEcm1v5DHhsf2T5QHnYKpJm49ZExVYRXvFj5rravtcZMgcZzNcucqLUW1Fm/VnIwPZTdpccj6gJnrUZJYRbN8F6CwN6kx8jyb yWsKR5OL0YdyxBMpcW66gl3CNdgnm6pYv42hhm04/IDZlGa5+Q4BfRZnKp+PM2gCLVYjGhgFSF/8bA== X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00006.txt.bz2 On 27.05.2017 18: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? Indeed, it seems yes. I now see in some documentation that "ffi_arg" C type must be used for=20 capturing return values. I'm not a complete idiot; I was taken for a ride by the simple example=20 from some (perhaps outdated?) libffi texinfo documentation. This one: #include #include int main() { ffi_cif cif; ffi_type *args[1]; void *values[1]; char *s; int rc; /* Initialize the argument info vectors */ args[0] =3D &ffi_type_pointer; values[0] =3D &s; /* Initialize the cif */ if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1, &ffi_type_uint, args) =3D=3D FFI_OK) { s =3D "Hello World!"; ffi_call(&cif, puts, &rc, values); /* rc now holds the result of the call to puts */ /* values holds a pointer to the function's arg, so to call puts() again all we need to do is change the value of s */ s =3D "This is cool!"; ffi_call(&cif, puts, &rc, values); } return 0; } Here, the return buffer rc is just "int" and not "ffi_arg". So, this=20 isn't correct for PPC64. The rc variable isn't large enough to buffer=20 the return value, and will alias the wrong end of it. Oops! puts("This is .. not so cool!"); :)