From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by sourceware.org (Postfix) with ESMTPS id 58F25385841A for ; Sat, 16 Oct 2021 08:08:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 58F25385841A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=iki.fi Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ot1-f49.google.com with SMTP id l24-20020a9d1c98000000b00552a5c6b23cso349070ota.9 for ; Sat, 16 Oct 2021 01:08:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=CJsGupfEpUdvr7ymOKLw3rV7was2D6HYg+6WfAO1C1U=; b=t724im1XuIqf8pc6/BxWy2RSlZGLhEn3vq2dhwf6T0DCrD1rD61vCGyFup6MTnum+C I8MBWP3a1ebQcm6QbQqgLRch7k8lxWoZI3hChbl0zQ7fexZbz6/MFxomiPmmuR6ZoqUA sGuDKraFPBXIAxxeT/K1zM1QfrvT3vPphc4+WXK/eaSQg9XB04i4m8VAN+28wamP5IJj IFH7MoWKVNPHrJ9f0mZ2k18gMER3xP/hCfphvw3/s+Tj6pY/BqliV4urRgya6WUQjGna dgsR6U5aPnJVlRBPSbQ7JPSSh5RypwfgydhB9S+tMF0gpvRlihWr4KUS7y15CwdY5750 0XgA== X-Gm-Message-State: AOAM531vAzqQVgFy6ROEkPdBM+nv2uJnYSZEDr5Zk7F9fbeN7dhNT/k0 sZHxisPCb5DfXa8mqhHnLDOxAuMrRZ0P/Pj2e8U= X-Google-Smtp-Source: ABdhPJyjGaQ4m8cZh61G1E4XV5uY1N0b2CwDDU3w8UJ4r6B+w3RXlXfRVoGZmzIcl4vNbvyiRoZuXkkRYOQEVGB/hQM= X-Received: by 2002:a05:6830:418c:: with SMTP id r12mr12058898otu.148.1634371733640; Sat, 16 Oct 2021 01:08:53 -0700 (PDT) MIME-Version: 1.0 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> <17c6b915c88.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <929290fbe61674eae18dbc7736fa5bf36755e907.camel@gmail.com> In-Reply-To: <929290fbe61674eae18dbc7736fa5bf36755e907.camel@gmail.com> Reply-To: jhi@iki.fi From: Jarkko Hietaniemi Date: Sat, 16 Oct 2021 11:08:42 +0300 Message-ID: Subject: Re: wide function pointer type To: Martin Uecker Cc: Daniel Colascione , "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>, Martin Uecker via Libffi-discuss X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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; charset="UTF-8" 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: Sat, 16 Oct 2021 08:08:57 -0000 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2787.pdf su 10. lokak. 2021 klo 22.25 Martin Uecker via Libffi-discuss ( libffi-discuss@sourceware.org) kirjoitti: > Am Sonntag, den 10.10.2021, 11:57 -0700 schrieb Daniel Colascione: > > > > 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. > > I see at least the following differences: > > - Simple user code does not know how to load the static chain > pointer into its ABI-specified register in a portable way. > > - A simple user struct works exactly for one function type, > so such a struct has to be created for all APIs separately. > > - One can not easily convert a regular pointer to a > simple user struct (this would require at least inserting > a branch at it each call site) > > - A simple user struct can be defined in different ways, > so there is no standard. > > - If a library defines a simple struct and another library > another simple struct, then these two structs are not > compatible even if defined identically. > > - Other languages or interface generating tools will not > know about the simple user struct, but will certainly > know about a standardized type. > > > > 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. > > I think the lambda proposal has a good chance, although > I am not sure it will make it already into C23. > There would be a conversion rule (as mentioned in > the proposal). > > C++ has std::function for a similar purpose. > > > > > 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. > > I tend to agree, but I do not see this happening. > > > > > > > > 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. > > This should be quite expensive though, if you use lots > of closures. > > > 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. > > Yes, you should try to propose this. > > > > 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 > > > -- There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen