From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71933 invoked by alias); 4 Nov 2015 07:31:07 -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 71913 invoked by uid 89); 4 Nov 2015 07:31:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,TBC,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 04 Nov 2015 07:31:05 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 50079AB464; Wed, 4 Nov 2015 07:31:04 +0000 (UTC) Received: from bigtime.twiddle.net (ovpn-116-34.ams2.redhat.com [10.36.116.34]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA47UxMH029393; Wed, 4 Nov 2015 02:31:02 -0500 Subject: Re: documentation patch, oddities, and proposals To: Tom Tromey , libffi-discuss References: <87d1vqe3e0.fsf@tromey.com> From: Richard Henderson Message-ID: <5639B430.2010807@redhat.com> Date: Wed, 04 Nov 2015 07:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87d1vqe3e0.fsf@tromey.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00092.txt.bz2 On 11/04/2015 06:32 AM, Tom Tromey wrote: > * The ffi_arg business for return values I (re-)learned from reading the > archvies. I still haven't fixed my own code to deal with this yet. > > I wasn't sure -- is this needed in some way for the closure API as > well? If so, and someone can explain where (that is, arguments, > return values, or both), I will write a documentation patch. As far as I can tell it's just historical, and now for api compatability with earlier libffi. But perhaps Anthony remembers more. > * I wanted to compute the layout of a struct. libffi does this > internally but doesn't expose the results. > > I think it would be great to have a new function to do this. In fact > I wrote one, but... Indeed. It would be very nice to require a separate layout call, rather than imply it from ffi_prep_cif. This would also nicely fix the problem that libgo encountered wrt zero-sized structures. > * ... this lead me to the discovery that ffi_prep_types modifies some of > the libffi globals, meaning that libffi is not type-safe when using > multiple ABIs. > > Currently, AFAICT, this only affects long doubles on PPC. So, not > quite as bad as it seems -- but still it is a bug. Indeed. I've thought about ways to fix this in the past, and the best I can think of imply an api+abi change. Basically, stop exporting all of the ffi_type_foo variables (which themselves imply nasty abi compatibility problems, due to the COPY relocs they require). Instead, have a function call taking an enumeration for the basic types, as well as the abi enum. Which means that ppc can have two separate structures for its longdouble, which means that both can be read-only. > * Also due to ffi_prep_types, you can't really use the size and > alignment fields of an ffi_type unless you know that the ABI hasn't > changed. And, because of this, you also can't share structure types > across ABIs. (Maybe that is obvious? It was a bit of a surprise to > me.) No, it's not obvious. Thankfully (?) ppc32 is the only offender here. > * As you can see from the docs, I also had to resort to some shenanigans > to get arrays and unions working. I think it would be preferable to > have FFI_TYPE_ARRAY and FFI_TYPE_UNION directly in the library. That would be nice. > * This doesn't impact the docs, but ffi.h.in is a mix of public and > private stuff. I think it would be nice to separate these. Indeed. > * I didn't write docs for the raw or java APIs. It's probably time for > those to die. > > * Someone who understands what it does should perhaps write > documentation for the Go closure code. Or, if this is only for use by > gccgo, then maybe it should be relegated to the aforementioned > internal-only header. Hmm.. They're certainly not truly internal functions, but I can't imagine ffi_prep_go_closure being of use to anything but libgo. Within Go itself, one would use the standard library to call out to C functions. On the other hand, ffi_call_go is useful to anyone wanting to call into a function written in Go. Though I expect writing general-purpose libraries in Go to be as rare as invisible pink unicorns... I'll have a look at the actual doc changes later. r~