Re: wide function pointer type

[Daniel Colascione <dancol@dancol.org>]

On October 10, 2021 11:47:18 Martin Uecker <ma.uecker@gmail.com> wrote:

> Am Sonntag, den 10.10.2021, 11:17 -0700 schrieb Daniel Colascione:
>> 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.
>
> 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. 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.

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


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

> 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