It encapsulates symbol lookup, possibly searching multiple libraries for a function. But that's not all: by wrapping Ffidl callout into an auto-generated Tcl procedure, it provides additional argument types that are pre-processed and post-processed before and after callout.
ffix also included some commands to manage in-memory buffers, thus allowing you to use functions with deferred input/output. This relies on Roger E Critchlow's Ffidl 0.6 (stubsymbol), while the other parts of ffix may work with Ffidl 0.5
This initial release of ffix is highly experimental and subject to changes in the API. -- Anton Kovalenko
When adding things to the core, there is always a trade-off between adding the useful functionality and keeping the core relatively small (hmm) and maintainable. But Ffidl has a huge potential usability and is yet relatively small in size.
Why do I think that there is a huge potential usability in Ffidl? Here is an example: 3 days ago I was looking for ODBC->TCL binding that would support unicode SQL types. I considered adapting Tclodbc... but I've decided instead to make a low-level API calls with Ffidl and create a high-level interface with snit. Now I have a drop-in replacement for Tclodbc that works with unicode types; if I'll need some ODBC3-specific feature, it'll take only a few minutes to add it to my project.
There is a question: would anyone bother implementing Tclodbc as a binary extension, if Ffidl were in the core? Well, I can't say for anyone, and ODBC is not that simple; it's possible that someone would write Tclodbc even in that case. However, I'm sure that a lot of binary extensions existing today would never be binary, but pure-Tcl, if the pure Tcl contained Ffidl out-of-the-box.
For some extensions, implementing them in C is justified. However, a lot of extensions are mere replacements for the missing Ffidl: the only thing they do is forwarding script commands to the OS or some external library.