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 9578E3858D3C for ; Sun, 10 Oct 2021 18:05:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9578E3858D3C Received: by mail-wr1-x429.google.com with SMTP id e3so14652258wrc.11 for ; Sun, 10 Oct 2021 11:05:04 -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:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=CJ+OEUIdqv0PngRT1XAZAVsrMgolPbvMlGDDSRAZxgs=; b=yzRbfKz252FezD3c90aZZcnz1GZY1Ai0igHP2hVIj0vZs+2rRpBm5E3GC7dnt9ZbAH ka2ELYEsoL6ruS45Pw7aLm+R/5vbkc2pF5xUQcUdYjS60BBflcXoIQq4WZLDB0e1pkSo /el10xPtAtV66JQY6O+VBRfjaac5haEoBwOCqgnHhHZRjq9b7Yo6if61x1zzNdQ0I/kp pah1IJ1Qo6pDWElTt+VA/S3TpS/umTv7lP+QVBGM032GcPXEY92wGyCSaVQur38VchEk yPkCA7s6t0bjQQlJPnEIoX8bRIr5hYqrZLvzlhx95E/PVWcpT7ri1eonVIsN8davzYlN k6LQ== X-Gm-Message-State: AOAM5333VYXEFW4eKOTkAXsj/aZloiD8tP/v4zLU+UDe7R92stcoKFY/ jZhtTL71+X5uhZQKjlgKLpU= X-Google-Smtp-Source: ABdhPJwMLYvfRT9DqyX/VbsWbs9CfPhAZFqaZPVbOFUBd/+b+0IAOarZ9eXMKE+wnke9y4vbhyFXdg== X-Received: by 2002:adf:a10f:: with SMTP id o15mr19509650wro.286.1633889103725; Sun, 10 Oct 2021 11:05:03 -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 k9sm5374760wrz.22.2021.10.10.11.05.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Oct 2021 11:05:03 -0700 (PDT) Message-ID: <742651c57616f676aea2ee8b4a05b24a23cbf974.camel@gmail.com> Subject: Re: wide function pointer type From: Martin Uecker To: Daniel Colascione , "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>, Martin Uecker via Libffi-discuss Date: Sun, 10 Oct 2021 20:05:02 +0200 In-Reply-To: <17c6b52d0d0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <09d27268d43fc4a8885695eba840faa4@mail.kylheku.com> <54e81ff3a4a6569798ba879c47392d4b19ec599b.camel@gmail.com> <17c6b52d0d0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> 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.4 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 18:05:06 -0000 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. Martin