[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.