From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 40D26385AC2D for ; Wed, 20 Oct 2021 09:21:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40D26385AC2D Received: by mail-wm1-x32a.google.com with SMTP id o24-20020a05600c511800b0030d9da600aeso8563284wms.4 for ; Wed, 20 Oct 2021 02:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=bny1CS02esScXOWyZaEkR1yrSlB1HF2zPBX7LF8ihP4=; b=Bpw4NqL5XHQubM+ADoHpmvi7qSGvfFpB8moRn5oseNqRqSjAdMIike3eKmMxYEyg/s 4KR7pyrQxZQShI7vbDdW6cazK+dUZGu8ZJQM131whmG0HFH+1S1tSEStWzsnN7vkCbSz 8VQLYM2RZPgerE2lkiirBwfXCAq7hZE166QY3odSsL8NqImzNx3C5qdW4g2bCiQ+8SNX eKcWsIMJfcRX1mjMTpG11S6fYBVFZeJSaodgsQyTTGvScdESaXPYcPJ+wHj8lLQN41BH 314tB3hRSMhjiFtVndtoWeAY6WTvuFU+kLfue4bUk14iT21C5HFPyrHhHecfdWoto/Tm y49Q== X-Gm-Message-State: AOAM5330CHPUqH23xRaPI0gOf6QCROcT1wuRO5+J4tWOzarcyd675TVj YpnH0SlBEjN4LltPOEAv2ng= X-Google-Smtp-Source: ABdhPJy8AzkavWvPlBvx0n8GwN+Irwi87IAMD+sEEh4yVMDXWYoudKFTd0uULn7RluVa0mlbinEOQA== X-Received: by 2002:adf:ab46:: with SMTP id r6mr50229066wrc.71.1634721667326; Wed, 20 Oct 2021 02:21:07 -0700 (PDT) Received: from nt-f071.wlcli.tugraz.at (nt-f071.wlcli.tugraz.at. [129.27.245.71]) by smtp.gmail.com with ESMTPSA id m15sm1505520wmq.0.2021.10.20.02.21.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Oct 2021 02:21:07 -0700 (PDT) Message-ID: <1f0500640675adfdc4c911987f68f307b2993407.camel@gmail.com> Subject: Re: wide function pointer type From: Martin Uecker To: Florian Weimer Cc: Martin Uecker via Libffi-discuss , Anthony Green Date: Wed, 20 Oct 2021 11:21:06 +0200 In-Reply-To: <878ryoxdsn.fsf@oldenburg.str.redhat.com> 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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:21:09 -0000 Am Mittwoch, den 20.10.2021, 11:10 +0200 schrieb Florian Weimer: > * 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. 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. I would expect a lot of update (in the long run) because there is now a 1:1 mapping for a function pointer type in other languages to the function type in C. > For many targets, even C and C++ compilers do not > always agree completely on the finer points. Unfortunately, e.g. atomics. But the goal and intention is interoperability. > Passing code and data pointer in separate arguments is > much more robust, and safely within the > interoperable ABI subset. It is not my experience that the void pointer based APIs are robust and safe. > Perhaps a set of standard attributes to describe the explicit closure > argument would be useful, though. I also thought about this (and this could be added too) but this does not solve all problems. Martin