3 ms·
> Automated FFI parsers. In 2021 I should be able to point any interpreted language at a C include file and have all the functions described in it turned into r
by RcouF1uZ4gsC 5y ago
> Automated FFI parsers. In 2021 I should be able to point any interpreted language at a C include file and have all the functions described in it turned into reasonably safe FFIed function calls,
The big issue with doing this is that C does not have enough of a type system to exactly specify the interface. Is that char pointer, a null terminated string, or is it a pointer to an untyped buffer? What is the ownership of the pointer you are passing in or is being returned from the function? Are you allowed to pass in null for the pointer parameter?
All of these are questions that the C type system does not tell you. You have to rely on some type of documentation to figure it out. And if you get it wrong, you have a memory leak at best or a security while at worse.
- andrewflnr 5y agoThere's definitely still a lot of scut work the compiler could (and therefore should, in my view anyway) be doing for you. Even if it got you to the point where you can setup those safety invariants in your interpreted (or whatever) language, that would be nice.
- _ph_ 5y agoI think this points to the real answer: libraries should be defined by something else than the C headers we are using now. All automated solutions or parsing C headers require a C compiler present and as you write, there is a lot left unspecified.
- contextfree 5y agoWindows has partly moved and is moving in this direction - WinRT (higher-level, C#-like but without requiring the .NET runtime and GC) APIs are already defined in metadata, and now Win32 (lower-level, C-style) APIs are being defined that way as well: https://github.com/microsoft/win32metadata/blob/master/docs/roadmap.md https://github.com/microsoft/win32metadata/blob/master/docs/...