From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTPS id 6A1BC3858419 for ; Wed, 20 Oct 2021 09:27:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6A1BC3858419 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-585-hpsUlZtwNhKFNsx6rvDTaA-1; Wed, 20 Oct 2021 05:27:08 -0400 X-MC-Unique: hpsUlZtwNhKFNsx6rvDTaA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A00CB80363C; Wed, 20 Oct 2021 09:27:07 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8C4AE64188; Wed, 20 Oct 2021 09:27:06 +0000 (UTC) From: Florian Weimer To: Martin Uecker Cc: Martin Uecker via Libffi-discuss , Anthony Green Subject: Re: wide function pointer type References: <9362563f8803f575d00c03835d2897b3836a7645.camel@gmail.com> <857da973fe5bbb94a363114262b57d42b35cc1f6.camel@gmail.com> <87czo2hjiq.fsf@oldenburg.str.redhat.com> <8d2ddbb76479ce3ad7f99acb3f0b79a6a8d1440b.camel@gmail.com> <87bl3lgyha.fsf@oldenburg.str.redhat.com> <6a0299e6b3c47cddd88b24d569fca8aeb4717aeb.camel@gmail.com> <87o87lfhi3.fsf@oldenburg.str.redhat.com> <878ryoxdsn.fsf@oldenburg.str.redhat.com> <1f0500640675adfdc4c911987f68f307b2993407.camel@gmail.com> Date: Wed, 20 Oct 2021 11:27:04 +0200 In-Reply-To: <1f0500640675adfdc4c911987f68f307b2993407.camel@gmail.com> (Martin Uecker's message of "Wed, 20 Oct 2021 11:21:06 +0200") Message-ID: <874k9cxd07.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 09:27:15 -0000 * Martin Uecker: >> I don't expect a lot of uptake for this. One problem is the suggested >> aggregate representation of wide function pointers. It's not exactly >> common for non-C implementations to implement those aspects of the >> platform C ABI. > > Can you explain what you mean by this? Usually non-C > implementations build on C ABI, so if the C ABI is > extended the extension is then available to them. In practice, the shared ABI is just a subset of what is required for full C. Often, support for pass-by-value struct and union arguments and return values are missing or implemented incorrectly (not according to the platform ABI). Other traditionally incomplete parts (relative to C90) are variadic functions and bitfields. Thanks, Florian