From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by sourceware.org (Postfix) with ESMTPS id 80BD93858D3C for ; Sun, 10 Oct 2021 17:44:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 80BD93858D3C Received: by mail-wr1-x429.google.com with SMTP id r10so48127012wra.12 for ; Sun, 10 Oct 2021 10:44:23 -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=vI60+PrgqIrp6G89VEZtP94zxp8UvPPi3rJMjhyl6Rs=; b=y/6RZYQc+5XfIO8PPPhZuBrQu6wrHJg0iqFwrmqJkx5AYnbSoaph7SfqPvmkxfGCB1 y6niV8FSMvEPMIKNq2qvW8ny2L0dm+IRdwblUfdqvLdn6/8EbOQwp+15lOfsq0nykd9z dheRQWwH/+eaYa1QGMeVZackrR68OucMIBRGmT0dzNVzOsWXvIyeodBkdXMUe1/9RcGk l3kfGjWjXTJUxyoH99e58HUfBIvAhLV3VsGh11gbBiDxuCI4muN2t2amOFI33F7LZngC Spa05d+kmsrmTJ3mYKrIQhCnltfGLIQzxs4fDcJOua59qfiAhW3dDD+HqfP0cV399AXZ NDDQ== X-Gm-Message-State: AOAM532CNZxByVsXeTxtMgMlC58cnEzKmVNmXjSSdepZ0dsflVQtijfz mHkr9ToDlmE9u4vAcM2orrFCW5RC1B0= X-Google-Smtp-Source: ABdhPJxRAIhrV0LWHEBIlN41h+m8wWqlesjjZCW0BgqWpeKQqgdTBtgg4sHkSnXfXb/3Y19AkCxwCQ== X-Received: by 2002:adf:9084:: with SMTP id i4mr18904977wri.304.1633887862614; Sun, 10 Oct 2021 10:44:22 -0700 (PDT) Received: from 2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at (2a02-8388-e205-e880-569c-680a-c69b-a1ad.cable.dynamic.v6.surfer.at. [2a02:8388:e205:e880:569c:680a:c69b:a1ad]) by smtp.gmail.com with ESMTPSA id d24sm5434018wmb.35.2021.10.10.10.44.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Oct 2021 10:44:22 -0700 (PDT) Message-ID: <54e81ff3a4a6569798ba879c47392d4b19ec599b.camel@gmail.com> Subject: Re: wide function pointer type From: Martin Uecker To: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: libffi-discuss@sourceware.org Date: Sun, 10 Oct 2021 19:44:21 +0200 In-Reply-To: <09d27268d43fc4a8885695eba840faa4@mail.kylheku.com> References: <09d27268d43fc4a8885695eba840faa4@mail.kylheku.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.3 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: Sun, 10 Oct 2021 17:44:25 -0000 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. Martin > Higher level languages that interface C or are built on C > do not agree on an exact representation for closures; > it's not a good idea to second guess them. Many languages > are perfectly able, in their implementations, to represent > function callable objects of all sorts using ordinary > pointer-sized reference values. What those values refer to > varies quite a bit. > > Callback mechanisms are often bound to OOP-style objects > rather than closures. The same context pointer is > associated with more than one callback. > > The context argument has the right flexibility to cover > all the situations that arise. > > In some library API's, the object pointer is registered > separately, and then other functions implicitly use it > when invoking callbacks, so it doesn't have to be passed > any more. > > Sometimes there are multiple callbacks, but one context > pointer, passed in one call: > > initiate_operation(arg, callback_context, > get_data_fn, progress_fn); > > Should there be a triple wide pointer just to roll three > arguments into one? >