[coldtea]

>A C interface (a function) is exposed only through its name, and no other data; the name does not encode either the number of the type of parameters, which means that you can’t reflectively load the ABI based off the symbols in a shared object.

What prevents GCC and Clang (and co from Intel/MS) saving a sidecar file next to a program/.so with all the functions and their argument types, struct structures, etc. in some agreed upon format for easy parsing / use? Could even be emitted based on some annotation/pragma like #export before the function declaration.

Is it just that nobody really cares to coordinate such a solution?

[rurban]

They already have it, and they call it a header file.

Better FFI's generate their definitions from such header files, called header parsers. (based on some CPP code). This problem was solved in the 80ies, but I guess forgotten by now.

[coldtea]

>They already have it, and they call it a header file

Some languages already use that for the purpose, but it's an ill fit. It's meant for the internal parser of the language, so you need to parse C code (even if it's just the header file syntax). And it wasn't created with FFI in mind, in the first place.

What I propose is a file intended for others wanting to FFI, and thus trivial to parse (could be a schema for a format with ubiquitus parsers, like XML, JSON, YAML, TOML, and co).

That would have the benefit of:

(1) being cross-language (every language that exposes functions with C calling conventions could produce such a file to allow others to interface with it.

(2) being trivial to parse and integrate with ffi facilities of different languages (e.g. ctypes)

(3) being extensible beyond the C-header files give (e.g. metadata about usage, or valid int ranges, even function documentation, etc).

[Flameeyes]

(Article author here.)

Yup, there's also the more common approach of implementing extensions in C (or equivalent), possibly with an intermediate language.

For example, Cython is a much more scalable approach, in my experience, than attempting to describe the interface in Python and using a libffi-style binding.

[bsder]

The best FFIs generate even the C header files from a single parent source.

See: Vulkan's vk.xml

[rurban]

True. I generate my dynamic API headers, code and test cases also automatically. In LibreDWG from some readable spec file. Because static code for 1000 of objects would be overkill. Unlike LiquidXML.

[ithkuil]

There is no need for a side car file; we could have an extra section in the binary (ELF or other formats) in the same vein we have debug (e.g. dwarf) and other metadata.

[coldtea]

Sure, it doesn't have to be sidecar (though as a sidecar you could add it next to existing binaries where you don't have upstream access as well and might be signed so you can't alter them).