From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18303 invoked by alias); 10 Nov 2015 23:36:33 -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 18287 invoked by uid 89); 10 Nov 2015 23:36:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: gproxy7-pub.mail.unifiedlayer.com Received: from gproxy7-pub.mail.unifiedlayer.com (HELO gproxy7-pub.mail.unifiedlayer.com) (70.40.196.235) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Tue, 10 Nov 2015 23:36:31 +0000 Received: (qmail 16888 invoked by uid 0); 10 Nov 2015 23:36:29 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 10 Nov 2015 23:36:29 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by CMOut01 with id fzcR1r0012f2jeq01zcUGy; Tue, 10 Nov 2015 16:36:28 -0700 X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=zstS-IiYAAAA:8 a=PnD2wP_eR3oA:10 a=j3B2vUqGZCcA:10 a=qtqOOiqGOCEA:10 a=Egepzb9oQM7DRssRl4oA:9 Received: from [71.218.1.35] (port=49785 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1ZwISf-00034q-Tk; Tue, 10 Nov 2015 16:36:26 -0700 From: Tom Tromey To: Richard Henderson Cc: Tom Tromey , libffi-discuss Subject: Re: documentation patch, oddities, and proposals References: <87d1vqe3e0.fsf@tromey.com> <5639B430.2010807@redhat.com> Date: Tue, 10 Nov 2015 23:36:00 -0000 In-Reply-To: <5639B430.2010807@redhat.com> (Richard Henderson's message of "Wed, 4 Nov 2015 08:30:56 +0100") Message-ID: <87si4dctqh.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {36111:box522.bluehost.com:elynrobi:tromey.com} {sentby:smtp auth 71.218.1.35 authed with tom+tromey.com} X-SW-Source: 2015/txt/msg00097.txt.bz2 I sent my documentation patch as a PR. [...] rth> Indeed. I've thought about ways to fix this in the past, and the best rth> I can think of imply an api+abi change. rth> Basically, stop exporting all of the ffi_type_foo variables (which rth> themselves imply nasty abi compatibility problems, due to the COPY rth> relocs they require). rth> Instead, have a function call taking an enumeration for the basic rth> types, as well as the abi enum. Which means that ppc can have two rth> separate structures for its longdouble, which means that both can be rth> read-only. Ok, following up on this, here's my wish-list if an ABI break is possible. * Require each ABI to have a string name and provide a way to look up ABI by name. This would let generic FFI wrappers expose ABIs to their callers without undue difficulty. This would be handy at least for Lisp bindings; and it seems reasonably lightweight. Also, document all ABIs -- not really an ABI problem, but worth pointing out. I suppose this could be added without breaking ABI. * As you said, get rid of ffi_type_* globals, replace with per-ABI calls using the FFI_TYPE_* constants. * Require a separate type-prep stage. For struct types allow an out parameter that would fill in field offsets. Requiring the separate call would make it possible for all the calls taking an ffi_type to be const-correct. * Add FFI_TYPE_UNION and FFI_TYPE_ARRAY. * Mark each ffi_type with an "ABI-specific" flag. This would taint a type as ABI-specific. Layout of a struct (or union or array) would propagate this flag from the members to the aggregate. The idea here is that in most cases this just doesn't matter and this would give an easy way to notice when it does. ffi_prep_cif could check this flag. Adding bitfield support might be nice, not sure. I don't care a whole lot about the ffi_arg thing, but if it isn't completely crazy to fix it, it might be a good idea. Tom