On Tue, Oct 14, 2025 at 10:46:19PM +0200, Josef Melcr wrote:
> > Perhaps the GNU attribute could specify both?
> > Arguments 2, 4 would mean fnptr is 2nd argument and its 1st argument is 4th,
> > so foo (1, fn, 2, &s) calls fn (&s).
> > And 2, 6, 5, 4 means foo (1, fn, 2, &s, &t, &u) calls fn (&u, &t, &s).
> > 0 is not a valid argument index, so that could be used as a separator to
> > where to map those arguments if not to 1-(nargs-1).
> > So, 2, 6, 5, 4, 0, 2, 4, 3 would mean foo (1, fn, 2, &s, &t, &u) calls
> > fn (?, &u, &s, &t).
> > I.e. 2, 4 would be equivalent to 2, 4, 0, 1 and 2, 6, 5, 4 equivalent
> > to 2, 6, 5, 4, 0, 1, 2, 3.
> Is that necessary? Currently, 0 serves as a marker for an unknown argument,
> the mapping is determined by the order. So fn (?, &u, &s, &t) is 2, 0, 6,
> 5, 4; the call in qsort_r would be 4, 0, 0, 5 and so on. I very well might
> be missing something, but I am not sure there is an advantage to stating the
> mapping explicitly, which makes it in my opinion less readable.
Ah, ok, with 0 as unknown argument it indeed expresses everything that is
needed. So forget this, just it will be essential to document the attribute
sufficiently (what exactly user promises). Which is that the function
pointer passed to it doesn't escape, the non-unknown arguments are passed
through without being changed, dereferenced and without escaping.
Shall it require that the non-unknown arguments have pointer/reference
types, or pointer/reference or scalar, or anything? I think it might be
useful to propagate even scalars like int, but propagating aggregates
(rather than pointers/references to aggregates) would be hard/weird.
Jakub
