public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Martin Uecker <ma.uecker@gmail.com>,
	"Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>,
	"Martin Uecker via Libffi-discuss"
	<libffi-discuss@sourceware.org>
Subject: Re: wide function pointer type
Date: Sun, 10 Oct 2021 11:17:19 -0700	[thread overview]
Message-ID: <17c6b6c63b0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org> (raw)
In-Reply-To: <742651c57616f676aea2ee8b4a05b24a23cbf974.camel@gmail.com>

On October 10, 2021 11:05:07 Martin Uecker <ma.uecker@gmail.com> 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
>> <libffi-discuss@sourceware.org> 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.

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. 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);

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.

  reply	other threads:[~2021-10-10 18:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-10 17:01 Kaz Kylheku (libffi)
2021-10-10 17:44 ` Martin Uecker
2021-10-10 17:49   ` Daniel Colascione
2021-10-10 18:05     ` Martin Uecker
2021-10-10 18:17       ` Daniel Colascione [this message]
2021-10-10 18:47         ` Martin Uecker
2021-10-10 18:57           ` Daniel Colascione
2021-10-10 19:24             ` Martin Uecker
2021-10-16  8:08               ` Jarkko Hietaniemi
2021-10-16  9:35                 ` Jarkko Hietaniemi
2021-10-10 18:31   ` Kaz Kylheku (libffi)
  -- strict thread matches above, loose matches on Subject: below --
2021-10-10 11:32 Martin Uecker
2021-10-17 23:35 ` Anthony Green
2021-10-18  5:33   ` Martin Uecker
2021-10-18  5:58     ` Martin Uecker
2021-10-18  7:36       ` Florian Weimer
2021-10-18  7:56         ` Martin Uecker
2021-10-19  9:22           ` Florian Weimer
2021-10-19  9:43             ` Martin Uecker
2021-10-19 10:15               ` Florian Weimer
2021-10-19 12:13                 ` Martin Uecker
2021-10-20  8:24                   ` Kaz Kylheku (libffi)
2021-10-20 18:52                     ` Martin Uecker
2021-10-20  9:10                   ` Florian Weimer
2021-10-20  9:21                     ` Martin Uecker
2021-10-20  9:27                       ` Florian Weimer
2021-10-20 17:27                     ` Kaz Kylheku (libffi)
2021-10-21  9:48                       ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17c6b6c63b0.283a.cc5b3318d7e9908e2c46732289705cb0@dancol.org \
    --to=dancol@dancol.org \
    --cc=382-725-6798@kylheku.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=ma.uecker@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).