Small query on CLinker

[Maurizio Cimadamore]

Hi Julian,
This question has come up, both internally and externally.

I agree that CLinker is a pretty general abstraction and there's nothing 
in it that is too C specific. The concepts of taking a function 
descriptor and turning it into a method handle, or, conversely, taking a 
method handle and turning it into a function pointer are reusable across 
different languages.

That said, there are a couple of ways in which language details can 
creep back in:

* not all linkers might support the same set of layouts in the provided 
function descriptor. For instance, a language might not have support for 
by-reference arguments (so that ValueLayout.ADDRESS is not an option). 
Or a language might not support composite types (so struct/union layouts 
are not possible)
* the support for variadic functions is pretty tied to how the ABI is 
defined; in C we have to know which arguments layouts in the function 
descriptor correspond to "variable arity" arguments, because the ABI 
needs to treat them differently.

Of course, one option would be to make the javadoc of CLinker language 
agnostic (this is easy - 90% of the javadoc already is) - and move the 
language-dependent details in the linker factory (e.g. set of supported 
layouts/parameters, handling of variable arity, etc.)

Thanks
Maurizio

On 23/03/2022 12:03, Julian Waters wrote:
> Hi all,
>
> Small query about CLinker, would it be more appropriate to rename it (And
> the systemCLinker method) to just "Linker" to better fit its role? It is
> after all supposed to be an abstraction for any sort of foreign interface,
> and I feel like the name CLinker would intuitively signify that it can
> *only* work with C and nothing else. Or would this undermine the fact that
> native calls have to follow the C ABI?
>
> best regards and have a great day,
> Julian