Why Foreign Function Interfaces are not an easy answer (2012) • Hacker News Board

Re: Why Foreign Function Interfaces are not an easy answer (2012)

#11

Post by coldtea » Sun, Jan 16, 2022, 11:03 PM UTC

ithkuil wrote: post #8

coldtea wrote: post #7

> 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 so…

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.

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

Re: Why Foreign Function Interfaces are not an easy answer (2012)

#12

Post by bsder » Mon, Jan 17, 2022, 3:02 AM UTC

rurban wrote: post #9

coldtea wrote: post #7

> 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 so…

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.

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

See: Vulkan's vk.xml

Re: Why Foreign Function Interfaces are not an easy answer (2012)

#13

Post by rurban » Mon, Jan 17, 2022, 6:51 AM UTC

bsder wrote: post #12

rurban wrote: post #9

Earlier quoted context omitted.

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.

The best FFIs generate even the C header files from a single parent source. See: Vulkan's vk.xml

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.

Re: Why Foreign Function Interfaces are not an easy answer (2012)

#14

Post by Flameeyes » Sun, Jan 23, 2022, 1:52 PM UTC

rurban wrote: post #9

coldtea wrote: post #7

> 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 so…

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.

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