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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id F1F0F385803B for ; Wed, 20 Oct 2021 09:10:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F1F0F385803B 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-35-dYFDRrpzPu2og4tVfoEYoA-1; Wed, 20 Oct 2021 05:10:05 -0400 X-MC-Unique: dYFDRrpzPu2og4tVfoEYoA-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 399D55074B; Wed, 20 Oct 2021 09:10:04 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 047806A8E5; Wed, 20 Oct 2021 09:10:02 +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> Date: Wed, 20 Oct 2021 11:10:00 +0200 In-Reply-To: (Martin Uecker's message of "Tue, 19 Oct 2021 14:13:12 +0200") Message-ID: <878ryoxdsn.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_H4, RCVD_IN_MSPIKE_WL, 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:10:08 -0000 * Martin Uecker: > One (of several) use cases is for language interoperability. > > A common problem is to pass a function of a high-level > language as a callback to an C API. This now often > requires special boiler plate code for each case and > there is no automatic way to do this. The fundamental > problem is that the C type can not express that a data > pointer belongs to a function pointer. > > void foo( > void (cb1)(void* data, int a), void* data1, > void* other_data); > > Here a human (and maybe also a machine) could guess > that data1 belongs to cb1 but not other_data. But > it is not clear and in more complicated cases > even less so. > > void foo(void (_Wide cb1)(int a), void* other_data); > > > With the new type that would be unambiguous (and > wrappers could then often be created automatically). > At least for the C API one would also expect ABI > stability. 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. For many targets, even C and C++ compilers do not always agree completely on the finer points. Passing code and data pointer in separate arguments is much more robust, and safely within the interoperable ABI subset. Perhaps a set of standard attributes to describe the explicit closure argument would be useful, though. Thanks, Florian