[o11c]

I was reading the `fontconfig` source recently (to help me understand what, exactly, is the difference between the various `fc-*` tools and their options) and some of the code scared me.

I thought, "for sure this is a use-after-free" ... but it happened to be safe because some function performed an undocumented incref, and the return value of that function was kept alive.

So this is definitely a high priority thing to port!

... I suppose the interesting question is: if some of my dependencies are ported, and some are not, is there any way a normal compiler can call into a Fil-C-compiled library for just a few functions?

[woodruffw]

> ... I suppose the interesting question is: if some of my dependencies are ported, and some are not, is there any way a normal compiler can call into a Fil-C-compiled library for just a few functions?

To my understanding, there's no way to do this: Fil-C is basically a managed runtime for native code, so the FFI implications are similar to those for Go or any other intrusive managed runtime. Which is to say that Fil-C could offer an FFI, but not without losing the blanket exit-instead-of-memory-unsafety guarantees it aims to offer.

[pizlonator]

Exactly right

[fulafel]

You could use a sandbox process and use some existing out of process calling system for it. This also disentangles the malloc systems of the modules.