From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 7BF953858D28 for ; Mon, 18 Oct 2021 05:33:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BF953858D28 Received: by mail-wr1-x436.google.com with SMTP id e12so39066384wra.4 for ; Sun, 17 Oct 2021 22:33:21 -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=RefUWW/d1ZDuNcarIkiJffupkzhD1wARB/RSC63v3Qc=; b=YeVXTL5+R2kJELm+jusAFDWY7HjMWYv7QVJNQChpmBPWDVjZznk5bYpMcgJzPKepa/ Y4SsxNTpfOp9GoE1augt/ns7H31zZs+zfJPupOPi4OjJKO6El8ZeAZI5UmaEEVmZWE9u 7jTfj3JZbEIWM/QSuXBOzJ5vyIFv0/d+GyWWHrLgm4u/CFZL3S4opDr/L117Ql6iLUVu HjdJ5BSct/q5Y7DT6ysXQIA+XJiUWm+Yu++gr03mgU7ms2hw/zFm5WW1qdvdBWqcUX6e fRvi4XGz8MTVVYHgRHx8K41rjQjQjIXW58TBBSo+fy9x/9kvDVXPv+vCJSCjG6YcEJiA ifPw== X-Gm-Message-State: AOAM531QrOA64CfHN6PsgjP/iV3Nig7+imFocy6jht/R+EEFy2PjYYrm Uz6yv6pWsJ6vm7oTrHrGSrc= X-Google-Smtp-Source: ABdhPJxqC56vdsB3Z9VWHuYITH6/bdagZL4TPWwnO3l9sfiPUqMR8na8xK7Rzd4649/0r6RNK4BV/A== X-Received: by 2002:a05:6000:2a4:: with SMTP id l4mr34214900wry.221.1634535200530; Sun, 17 Oct 2021 22:33:20 -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 y191sm19868146wmc.36.2021.10.17.22.33.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Oct 2021 22:33:20 -0700 (PDT) Message-ID: Subject: Re: wide function pointer type From: Martin Uecker To: Anthony Green Cc: libffi-discuss Date: Mon, 18 Oct 2021 07:33:18 +0200 In-Reply-To: References: <9362563f8803f575d00c03835d2897b3836a7645.camel@gmail.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.5 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: Mon, 18 Oct 2021 05:33:22 -0000 Hi Anthony, Am Sonntag, den 17.10.2021, 19:35 -0400 schrieb Anthony Green: > Hi Martin, > > I haven't read the whole proposal yet, but I'll try to this week. I > did, however, read the first paragraph, and it says: "Trying to use > regular function pointers for callbacks with data requires run-time > code generation (e.g. nested functions in GCC or XL C, and closures in > libffi [1]) but this is complex, inefficient, and problematic from a > security point of view." > > This is no longer true for libffi on the important Linux platforms. > We use static code templates that are placed in memory at a fixed, > predetermined distance from the data they reference. There is no > runtime code generation. Well, to be fair, perhaps it is still > complex, but it's far more secure than before. > > Thanks for sharing. I'm not a language expert, but I know others here are. Thank you for your comments! I had to submit this to WG14 to meet the deadline for C23. So the final version (so far) is here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2787.pdf Of course, it is still possible to modify the proposal later. It is great to hear that libffi can create trampolines without run-time code generation! We previously discussed such an approach also for GCC, but nothing was implemented. Martin > AG > > On Sun, Oct 10, 2021 at 7:32 AM 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. > > > > An early draft can be found here: > > > > http://wwwuser.gwdg.de/~muecker1/wide_v4.pdf > > > > > > I thought you might be interested and I would love > > to hear your feedback. > > > > Martin > > > > > >