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 89043385843C for ; Sun, 10 Oct 2021 18:57:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 89043385843C 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=vh15HVx8zMV3/TrdQRTB3pNm+8b47GSQNe6JmCzD248=; b=ALZmwh3bBgPh6TSJ/w8m+GEmGz g1qgrZReqconpvN5uEB9pujbvLDgD6rBjzD82HA+KG4e72s4eZpU31AOi+zQ31IrixHlQNhEYzKJS C5QAPH10LTQsej3NCwgEMoElPU0PIW9W5+hkgf0ta7lhP81bhMgJbKSNZKUNgEcOeA6USS/ahrTRD D3hjXxrGlLZJhuWgLr3wrLw0Y1qecE8/LbMDbMj0oR+zjD7t38Rw+sEyD+8kaDVrkXo/NfqVfswDE TGdnI/N7I/9yXx44Ow6NEeMFmip2uV5R8h+TqQV3invzG6eUwR5TMNpr+qB4Rhn+kxojeTMF2IgCx T0rHF9aA==; Received: from [172.92.145.124] (port=37186 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 1mZe11-00055f-5K; Sun, 10 Oct 2021 11:57:43 -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:57:41 -0700 Message-ID: <17c6b915c88.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> In-Reply-To: <7e6bdb9ddd6add840ec46a9069722f27c162d273.camel@gmail.com> References: <09d27268d43fc4a8885695eba840faa4@mail.kylheku.com> <54e81ff3a4a6569798ba879c47392d4b19ec599b.camel@gmail.com> <17c6b52d0d0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <742651c57616f676aea2ee8b4a05b24a23cbf974.camel@gmail.com> <17c6b6c63b0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <7e6bdb9ddd6add840ec46a9069722f27c162d273.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.8 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:57:48 -0000 On October 10, 2021 11:47:18 Martin Uecker wrote: > Am Sonntag, den 10.10.2021, 11:17 -0700 schrieb Daniel Colascione: >> 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. > > I wonder why you think it does not address > these problems? Because there's no difference between your proposal and a simple user struct that does the same thing. The language could get lambdas one day (though I doubt it), but if it does, each lambda will likely have a unique and anonymous type (like in C++) and won't fit in your wide function pointer struct anyway. >> 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. > > I also would love to have this, but see below... > >> 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); > > A void* might not be big enough for a callable function > pointer an all architectures supported by C so this > needs to return something like > > void (*)(); > > > (for POSIX this is not a problem) Yeah, although at this point, I'm in favor of standardizing things that are de facto universal anyway. POSIX for example mandates that NULL is all zero bits and that function pointers fit in void*, and I think it's time for C to just acknowledge the same. > > >> 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. > > One problem could be that this requires generating > trampolines at run-time (and it is not clear we > can do this everywhere where C is supported) or > having a fixed set of preallocated trampolines. Or remapping a fixed set of trampolines, like libffi does on some platforms. The new stdclosure feature would have to be optional, yes, but in practice it would be supported everywhere people write programs except maybe a few microcontrollers and DSPs. > The other limitation (which the new type would > avoid) is the need for dynamic resource allocation, > which is sometimes not desirable. > > But I would love to see such a proposal > brought forward. > > Martin