Re: wide function pointer type

["Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>]

On 2021-10-19 05:13, Martin Uecker via Libffi-discuss wrote:
> void foo(
>   void (cb1)(void* data, int a), void* data1,
>   void* other_data);
> 
> Here a human (and maybe also a machine) could guess
> that data1 belongs to cb1 but not other_data.  But
> it is not clear and in more complicated cases
> even less so.

That's a property of almost every C API. You cannot
guess the properties from the declaration alone.

If memcpy didn't have the const on the source
argument, you couldn't guess which argument is
the destination and which is the source.

                                 y
Argument names and analogy to x    tell you
which argument of pow is the base and which the
exponent.

That's the job of documentation.

A declarative mechanism which indicates that a given
context parameter goes with a given function could
exist instead of _Wide.

Such a thing was introduced 22 years ago for VLA's:

   void fun(int m, double a[m]);

An obvious convention is possible, and often occurs
in practice: namely, the context parameter in the API
function is given a name which exactly matches the
one in the function pointer:

   void foo(void (cb1)(void *the_context, int a),
            void *unrelated_data,
            void *the_context);

Your proposal also assumes that closures must always
be specified as two argument words, which is an
inappropriate choice to foist onto programmers.

So that is to say, you're taking it for granted that
you want to keep a distinct disadvantage of the
current approach and just wrap it in some syntactic
sugar machinery so that the two arguments appear
encapsulated as some _Wide thing passed by value.

But callback interfaces can easily use just a single
argument word to point to a object that is passed
with reference semantics; that object has a function
and context data.

In high level languages with closures, like Lisp
dialects, closures are of the same "size" as other
values; e.g. 32 or 64 bit pointer-sized word or
what have you.

C++ callback objects are usually one pointer also.

    void f(CallBackBase *cb)
    {
       (*cb)(42); // via operator ()
       // or
       cb->callBack(42); // regular member function
    }

C programs do this too:

    void f(struct obj *o)
    {
       o->ops->callback(o, 42);
    }

Or with the ops table in the object instance:

    void f(struct obj *o)
    {
       o->ops.callback(o, 42);
    }

The idea that all callback interfaces in C
use a function and a void * argument is a false; you
have to survey the entire field of practice in this general
area.

> void foo(void (_Wide cb1)(int a), void* other_data);

Without _Wide, we have

   void (cb1)(int a)

That (cb1)(int a) is a function declarator (with superfluous
parentheses); but when that occurs as a parameter, it
declares a function pointer: it is equivalent to:

   void (*cb1)(int a)

But it looks like

    void (_Wide cb1)(int)

might not be similarly equivalent to

    void (_Wide *cb1)(int)

and the difference could be useful.

Furthermore, given that you can have a _Wide value W, or
a pointer to a _Wide value PW, do you call them using different
syntax?

Is it just W(arg, ...) and PW(arg, ....)?

Or do we require (*PW)(arg, ...)?

If we don't require it, is it because of a decay rule, so that
we can write PW(arg, ...) or (*PW)(arg, ...) or (**PW)(arg, ...)?
and same with W? Or is it due to separately articulated semantics:
that the function call operator works with a _Wide and a
pointer-to_Wide, without any "decay" conversion going on?