From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dancol.org (dancol.org [IPv6:2600:3c01:e000:3d8::1]) by sourceware.org (Postfix) with ESMTPS id 013693858D3C for ; Sun, 10 Oct 2021 18:17:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 013693858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dancol.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dancol.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID: Date:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VI+Oj09yIUuUU3PX42hGu4WBm2BlKyuGdS3eNfdc2Qs=; b=LSdWVmaFLDXkvbQUgPN9yDrrMa NdmCjJ03Wt6pX9w4+APB9F/NwOKsxMAorJw+5qbO6GHpS9Cp8JvY4xqsiR/WOMzuWdb7niBsqbma9 YC+rJtqykk4Xz6oCLGzXkO4jwkK+zlmDhUHlmb8u4LzCROYuRT1Tk9LVlXSoW2OrBL5JFq23/QD3f LI2EikuqntlchXbhv0MVfXG+DlXGcBCXdp57NsjDfGyAUssxNlvSG0Q0Q8s3v46oZKcvjKY7cJYfF v9tUEeYdPoCHYKN1dtt1TfjH6SSAgUAgJm87NebUHaK/6hxl+D1ZpY+I4r1DiNXmATBZbUbDnaY1e 9xCgarPw==; Received: from [172.92.145.124] (port=48796 helo=[192.168.86.240]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1mZdNy-00050C-0O; Sun, 10 Oct 2021 11:17:22 -0700 From: Daniel Colascione To: Martin Uecker , "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>, "Martin Uecker via Libffi-discuss" Date: Sun, 10 Oct 2021 11:17:19 -0700 Message-ID: <17c6b6c63b0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> In-Reply-To: <742651c57616f676aea2ee8b4a05b24a23cbf974.camel@gmail.com> References: <09d27268d43fc4a8885695eba840faa4@mail.kylheku.com> <54e81ff3a4a6569798ba879c47392d4b19ec599b.camel@gmail.com> <17c6b52d0d0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <742651c57616f676aea2ee8b4a05b24a23cbf974.camel@gmail.com> User-Agent: AquaMail/1.31.0-1857 (build: 103101002) Subject: Re: wide function pointer type MIME-Version: 1.0 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, SPF_HELO_PASS, 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 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sun, 10 Oct 2021 18:17:26 -0000 On October 10, 2021 11:05:07 Martin Uecker wrote: > Am Sonntag, den 10.10.2021, 10:49 -0700 schrieb Daniel Colascione: >> On October 10, 2021 10:44:32 Martin Uecker via Libffi-discuss >> wrote: >> >>> Am Sonntag, den 10.10.2021, 10:01 -0700 schrieb Kaz Kylheku (libffi): >>>> On 2021-10-10 04:32, Martin Uecker via Libffi-discuss wrote: >>>>> Hi all, >>>>> >>>>> I will propose a wide function pointer type (actually >>>>> a wide function type) to WG14 for C23 as a common >>>>> type for callbacks, closures, which now require an >>>>> additional void pointer argument in C APIs. This >>>>> is intended to be compatible with ABIs with now >>>>> use a static chain register. >>>> >>>> Opposed. There is nothing wrong with separate arguments >>>> for function pointer and context. >>> >>> Noted. Your argument sbelow all boil down to the point >>> that there are cases where it might not be the ideal >>> choice. But nobody forces anyone to use it. >> "I like it" is not by itself a rationale for including something in a core >> language standard. This is not something that should be in C. Why, >> precisely, can't you just define a struct with two fields and make that >> your closure type? > > Sure. There are at least five reasons: > > - one now does has to do it manually which is > inconvenient because it has to be done for each type, > although this a common pattern which is trivial > to automate. > > - APIs are often unsafe because they have to use > void pointer to be generic. When the void pointer > can be packaged into the wide pointer this problem > goes away. > > - APIs are often different for no good reason. > Having a standard approach would make this more > canonical, hence simpler and less error prone, > and also more compatible - requiring less adapter > code. > > - There are APIs where a pointer to a > function is expected but there is no data pointer. > Then other languages have a problem interfacing > with such APIs. (or why does libffi generate > trampolines?) > > - Finally, C might get lambda expressions > which are far more useful with such a pointer type. > (for nested function you could avoid executable > stack). > > > All five are good reasons to put a standard > approach in the core language in my opinion. > > > But I am actually not interested in this discussion > and do not have time for it. > > I am more interested in constructive technical > feedback. Your proposal doesn't actually solve any of these problems though, and as we agree, users can already trivially make their own closure types. What *would* be interesting is a new standard library facility for making libffi-style closures and a standard struct type for packaging the things. *That's* something that could be justified for inclusion in a standard library, since it's not something that programs can make on their own without the kind of platform specific glue that libffi provides. Basically, the interface would look something like this: typedef opaque_mumble stdclosure_t; // Returns a callable function pointer or NULL on error with errno set void* stdclosure_init(stdclosure_t* closure, void* fnptr, void* data); void stsclosure_destroy(stdclosure_t* closure); The function pointer returned by stdclosure_init would, when called, call FNPTR with an extra initial parameter (or trailing parameter or something) of type void* and value DATA and all the remaining parameters with which it was called. This facility would actually probably have to be more complicated in real life due to varying platform ABIs, but you get the idea. This is something that could belong in the standard because it'd provide a generic abstraction for something every platform can do but that every platform has to do in a slightly different way.