Re: wide function pointer type

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

On 2021-10-20 02:10, Florian Weimer via Libffi-discuss wrote:
> Perhaps a set of standard attributes to describe the explicit closure
> argument would be useful, though.

For what purpose though? If there is some attribute mechanism in the 
syntax,
what translation decision does it drive? Or else, what diagnostic 
purpose?

Variable length arrays use matching names:

   void f(int x, double array[x])

the size attribute of the array is linked to the x parameter by name.

This is semantically important, because inside the function, the
run-time size of the array is computable with "sizeof array",
and that is derived from the value of x.

If the compiler knows that some closure argument c is linked with a
function f, what special treatment can it perform?

The function could be callable with fewer arguments, such that
c is implicitly inserted into the call.

Or, perhaps more usefully, we might be interested in diagnosing the
situation when the program neglects to pass the context parameter
to the function.

But if all we have is some parameter attributes, that is of limited
use; what if the function want to store those
two pieces into some structure, so that some other function
will later call f(c, ...).

The annotation mechanism would have to be propagated to all the
places in the program where the f value can reach; which means
additional declaration material in multiple places. If a structure
stores a function pointer and context value, we need to be able
to relate them in a structure, and so forth.

Imagine we had:

    struct callback {
      void *c __attribute__((context (f)));
      void (*f)(void *context);
    };

Let's use GCC-like attribute syntax with the understanding
that the actual syntax could be something else.

    void fun(void *context _attribute__ ((context (f))),
             void *other,
             void (*f)(void *))
    {
       struct callback cb;
       cb.f = f;
       cb.c = other; // ERROR
    }

This function could be diagnosable; however, depending on the exact
rules, it could requires data flow techniques, difficult to implement
without optimization.

The semantic constraint rules could be as simple as:

1. If either the members *f* or *c* are assigned, the other one
    must be assigned in the same expression, or adjacent statements
    of a compound statement, such that no other operation intervenes
    between the assignments.

2. Both members must be assigned from a linked pair. The assigned
    values are a linked function-context argument pair, or
    linked function-context members of the same structure.

3. In a struct definition with an initializer, if one linked member
    has an explicit initializer, the other must have one also, and
    the values must be a linked pair.

The only ingredient missing is the problem to go with this wonderful 
solution!