From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121033 invoked by alias); 29 May 2017 12:31:17 -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 120995 invoked by uid 89); 29 May 2017 12:31:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=overdue, bitten, Modra, modra X-HELO: gproxy4.mail.unifiedlayer.com Received: from gproxy4-pub.mail.unifiedlayer.com (HELO gproxy4.mail.unifiedlayer.com) (69.89.23.142) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 May 2017 12:31:15 +0000 Received: from cmgw3 (unknown [10.0.90.84]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 842F6175C38 for ; Mon, 29 May 2017 06:31:17 -0600 (MDT) Received: from box522.bluehost.com ([74.220.219.122]) by cmgw3 with id SCXE1v0082f2jeq01CXHzE; Mon, 29 May 2017 06:31:17 -0600 X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=tJ8p9aeEuA8A:10 a=74gXjxbcStnNjcdTEMEA:9 Received: from 174-29-43-217.hlrn.qwest.net ([174.29.43.217]:51726 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dFJpK-0002Oy-1B; Mon, 29 May 2017 06:31:14 -0600 From: Tom Tromey To: "Kaz Kylheku \(libffi\)" <382-725-6798@kylheku.com> Cc: libffi-discuss@sourceware.org Subject: Re: Cosure return value issue on Linux PPC64 References: <53985e874a349c551e7943677d21c766@mail.kylheku.com> Date: Mon, 29 May 2017 12:31:00 -0000 In-Reply-To: <53985e874a349c551e7943677d21c766@mail.kylheku.com> (Kaz Kylheku's message of "Sat, 27 May 2017 09:59:36 -0700") Message-ID: <8737bnetf4.fsf@bapiya> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Exim-ID: 1dFJpK-0002Oy-1B X-Source-Sender: 174-29-43-217.hlrn.qwest.net (bapiya) [174.29.43.217]:51726 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00011.txt.bz2 Kaz> Is this documented somewhere? A while back I tried to document all these little oddities in the manual. It's difficult and ABI-breaking to fix libffi to be more in line with user expectation, but at least in the meantime the docs can be correct... The closure docs say: @item ret [...] Otherwise, @var{fun} must fill the object to which this points, following the same special promotion behavior as @code{ffi_call}. That is, in most cases, @var{ret} points to an object of exactly the size of the type specified when @var{cif} was constructed. However, integral types narrower than the system register size are widened. In these cases your program may assume that @var{ret} points to an @code{ffi_arg} object. I hope this helps, but if it's still insufficiently clear, I'd appreciate suggestions for how to improve it. >From your other note: Kaz> I'm not a complete idiot; I was taken for a ride by the simple Kaz> example from some (perhaps outdated?) libffi texinfo Kaz> documentation. This one: You're definitely not an idiot, this has bitten many people, has been asked on StackOverflow, has been filed as a bug in github a few times, etc. Alan Modra fixed up this documentation example back in 2013, according to git blame. Seems like libffi is overdue for a release :-) Anyway, I think the in-tree docs should be a bit clearer here. For example they mention the promotion behavior now. Tom