Re: wide function pointer type

[Jarkko Hietaniemi <jhi@iki.fi>]

Related:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p2303r0.pdf

la 16. lokak. 2021 klo 11.08 Jarkko Hietaniemi (jhi@iki.fi) kirjoitti:

> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2787.pdf
>
> su 10. lokak. 2021 klo 22.25 Martin Uecker via Libffi-discuss (
> libffi-discuss@sourceware.org) kirjoitti:
>
>> Am Sonntag, den 10.10.2021, 11:57 -0700 schrieb Daniel Colascione:
>> >
>> > 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.
>>
>> I see at least the following differences:
>>
>> - Simple user code does not know how to load the static chain
>> pointer into its ABI-specified register in a portable way.
>>
>> - A simple user struct works exactly for one function type,
>> so such a struct has to be created for all APIs separately.
>>
>> - One can not easily convert a regular pointer to a
>> simple user struct (this would require at least inserting
>> a branch at it each call site)
>>
>> - A simple user struct can be defined in different ways,
>> so there is no standard.
>>
>> - If a library defines a simple struct and another library
>> another simple struct, then these two structs are not
>> compatible even if defined identically.
>>
>> - Other languages or interface generating tools will not
>> know about the simple user struct, but will certainly
>> know about a standardized type.
>>
>>
>> >  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.
>>
>> I think the lambda proposal has a good chance, although
>> I am not sure it will make it already into C23.
>> There would be a conversion rule (as mentioned in
>> the proposal).
>>
>> C++ has std::function for a similar purpose.
>>
>> > > > 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.
>>
>> I tend to agree, but I do not see this happening.
>>
>> > >
>> > > > 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.
>>
>> This should be quite expensive though, if you use lots
>> of closures.
>>
>> >  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.
>>
>> Yes, you should try to propose this.
>>
>> > > 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
>>
>>
>>
>
> --
> There is this special biologist word we use for 'stable'. It is 'dead'. --
> Jack Cohen
>


-- 
There is this special biologist word we use for 'stable'. It is 'dead'. --
Jack Cohen