7 ms·

Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C

67 points by jhatemyjob 11mo ago

rvz 11mo ago
What is the actual catch with Fil-C? Memory safety for C based projects without a complete rewrite sounds like a very good idea, but there must be some pitfalls in this approach which this would not work in some cases. In some other memory-safety circles (Rust, Zig, etc) I'm going to expect that this is going to be heavily scrutinized over the claims made by the author of Fil-C. But great work on this nonetheless.
- pizlonator 11mo ago
  Author here! :-) > What is the actual catch with Fil-C? Two things: - Not ABI compatible with Yolo-C. So, you have to recompile the whole stack. This is both a major catch, and it is both a bug and a feature. It's a bug for obvious reasons. It's a feature because it means I'll probably be the first to have a totally usable, totally memory safe desktop environment. - In my testing, it's between 1.2x and 4x slower than Yolo-C. It uses between 2x and 3x more memory. Others have observed higher overheads in certain tests (I've heard of some things being 8x slower). How much this matters depends on your perspective. Imagine running your desktop environment on a 4x slower computer with 3x less memory. You've probably done exactly this and you probably survived the experience. So the catch is: Fil-C is for folks who want the security benefits badly enough. It's not obvious that either of these catches are fundamental. The Fil-C development philosophy is very much to get something working first, which means downscoping. That's why I didn't include Yolo-C ABI compat as a goal at all and it's also why I haven't done as many optimizations as I should have. If you look at my GitHub you'll see >20 open issues with performance optimization ideas. > In some other memory-safety circles (Rust, Zig, etc) I'm going to expect that this is going to be heavily scrutinized over the claims made by the author of Fil-C. Of course this has happened. Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on an unsafe stack (like calling into libc, but also lots of other dependent libraries that are written in C). Fil-C doesn't have an `unsafe` statement and the dependencies are all recompiled with Fil-C.
  - IshKebab 11mo ago
    > Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Have you considered making... Fil-Zig? Would it be easier to do because Zig is already fairly far ahead of C in terms of safety? > Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on an unsafe stack (like calling into libc, but also lots of other dependent libraries that are written in C). To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe", it's just that PAM isn't any safer (because it's unmodified C). Also you can use Rust without libc - https://github.com/sunfishcode/mustang https://github.com/sunfishcode/mustang - unfortunately it doesn't seem to have gained much traction which I think is a shame because glibc is a curse. Most Rust programs actually have very few C dependencies. The big exceptions are libc and OpenSSL, but I think they'll be excised eventually.
    - pizlonator 11mo ago
      > To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe" That's exactly my point. sudo compiled with Fil-C: uses pam compiled with Fil-C, and all of pam's dependencies are compiled with Fil-C, so the whole thing is memory safe. sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe. pam is quite big and pulls in other unsafe dependencies
      - IshKebab 11mo ago
        > sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe Well it is, it's just that it doesn't magically make PAM safe either. We're not disagreeing about anything technical, I just think it's slightly unfair to say Rust isn't as safe as Fil-C based on that. It is as safe; it just can't automatically make all C code safer like Fil-C can (and CHERI, etc.).
  - whitequark_ 11mo ago
    [flagged]
- josephg 11mo ago
  > What is the actual catch with Fil-C? It sounds like Fil-C combines the ergonomics of C with the performance of Python. It might have a beautiful niche for safely sandboxing legacy code. But I don’t see any compelling reason to use it for new code. Modern GC languages are much more ergonomic than C and better optimised. C#, Java, JavaScript and Go are all easier to write, they have better tooling and they will probably all perform as well or better than Fil-C in its current state.
  - jhatemyjob 11mo ago
    [flagged]
    - bigfishrunning 11mo ago
      This is super gross, but I don't see it is relevant... Does java's ecosystem suddenly not solve the same problems it did before?
      - jhatemyjob 11mo ago
        I think it's interesting! Don't you? A fun fact of history most people don't know.
  - drnick1 11mo ago
    The ergonomics of C are excellent and the performance seems to be more like Java or C# than Python. The point is that you don't have to rewrite anything, so even the ergonomics of C don't matter.
    - josephg 11mo ago
      > The ergonomics of C are excellent That is a matter of opinion. Personally when I write C, I miss memory safety. And thread safety. I miss non-nullable types. I miss having a good way to return results. And generics. And tuples. And real enums (sum types). I miss having a sane build system. I miss having IDEs that just work with my projects. I miss having a well designed standard library. I miss being able to hit build and have it more or less work on every OS. I miss having a good package manager. And a sane macro language. I wish I didn't need to write header files. And I wish my header files didn't need to be parsed MxN times. I miss fixed integer types just being built into the language - like u8/u16/u32/... And real strings. And on and on. C compilers are fast and mature, so that's a plus. And C binaries are tiny. I mean, C has aged surprisingly well given the language is 53 years old. But its a really old language. And it shows. I would never use it for a new project, because it seems worse in every way compared to languages like Zig, Odin and Rust. > and the performance seems to be more like Java or C# than Python. Alright, I was exaggerating. But I still don't want my linux workstation to feel like a big java program. > The point is that you don't have to rewrite anything, so even the ergonomics of C don't matter. As I said in another comment, I really agree with this. Fil-C makes a lot of sense to me if the goal is to simply take existing legacy software and recompile it in a more memory safe way. But I don't think that's how the developers see it. I think they want fil-C so rust developers shut up, and they can go back to writing C code forever and ever and ever.
o11c 11mo ago
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 11mo ago
  > ... 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 11mo ago
    Exactly right
  - deleted 11mo ago
    [deleted]
- fulafel 11mo ago
  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.
malkia 11mo ago
If Fil-C requires complete recompile of ".c" code how does it deal with calls to the OS - Does it rewrap them (like Go?). I'm bit uncertain here...
- o11c 11mo ago
  It uses a sandwich; see https://fil-c.org/runtime https://fil-c.org/runtime
  - malkia 11mo ago
    Thank you!!!

67 points by jhatemyjob 11mo ago

rvz 11mo ago

What is the actual catch with Fil-C? Memory safety for C based projects without a complete rewrite sounds like a very good idea, but there must be some pitfalls in this approach which this would not work in some cases. In some other memory-safety circles (Rust, Zig, etc) I'm going to expect that this is going to be heavily scrutinized over the claims made by the author of Fil-C. But great work on this nonetheless.

pizlonator 11mo ago
Author here! :-) > What is the actual catch with Fil-C? Two things: - Not ABI compatible with Yolo-C. So, you have to recompile the whole stack. This is both a major catch, and it is both a bug and a feature. It's a bug for obvious reasons. It's a feature because it means I'll probably be the first to have a totally usable, totally memory safe desktop environment. - In my testing, it's between 1.2x and 4x slower than Yolo-C. It uses between 2x and 3x more memory. Others have observed higher overheads in certain tests (I've heard of some things being 8x slower). How much this matters depends on your perspective. Imagine running your desktop environment on a 4x slower computer with 3x less memory. You've probably done exactly this and you probably survived the experience. So the catch is: Fil-C is for folks who want the security benefits badly enough. It's not obvious that either of these catches are fundamental. The Fil-C development philosophy is very much to get something working first, which means downscoping. That's why I didn't include Yolo-C ABI compat as a goal at all and it's also why I haven't done as many optimizations as I should have. If you look at my GitHub you'll see >20 open issues with performance optimization ideas. > In some other memory-safety circles (Rust, Zig, etc) I'm going to expect that this is going to be heavily scrutinized over the claims made by the author of Fil-C. Of course this has happened. Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on an unsafe stack (like calling into libc, but also lots of other dependent libraries that are written in C). Fil-C doesn't have an `unsafe` statement and the dependencies are all recompiled with Fil-C.
- IshKebab 11mo ago
  > Zig is definitely not as safe as either Rust or Fil-C, since Zig doesn't have a great story for use after free. Have you considered making... Fil-Zig? Would it be easier to do because Zig is already fairly far ahead of C in terms of safety? > Rust is less safe than Fil-C in practice, because Rust code uses `unsafe` a lot (>100 uses of `unsafe` in uutils and sudo-rs, for example), and Rust code ends up depending on an unsafe stack (like calling into libc, but also lots of other dependent libraries that are written in C). To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe", it's just that PAM isn't any safer (because it's unmodified C). Also you can use Rust without libc - https://github.com/sunfishcode/mustang https://github.com/sunfishcode/mustang - unfortunately it doesn't seem to have gained much traction which I think is a shame because glibc is a curse. Most Rust programs actually have very few C dependencies. The big exceptions are libc and OpenSSL, but I think they'll be excised eventually.
  - pizlonator 11mo ago
    > To be fair `sudo-rs`'s usage of unsafe is all there just to interface with C code (e.g. PAM) so it isn't really sudo-rs that is "less safe" That's exactly my point. sudo compiled with Fil-C: uses pam compiled with Fil-C, and all of pam's dependencies are compiled with Fil-C, so the whole thing is memory safe. sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe. pam is quite big and pulls in other unsafe dependencies
    - IshKebab 11mo ago
      > sudo-rs: uses pam compiled with Yolo-C, so it's not actually safe Well it is, it's just that it doesn't magically make PAM safe either. We're not disagreeing about anything technical, I just think it's slightly unfair to say Rust isn't as safe as Fil-C based on that. It is as safe; it just can't automatically make all C code safer like Fil-C can (and CHERI, etc.).
- whitequark_ 11mo ago
  [flagged]
josephg 11mo ago
> What is the actual catch with Fil-C? It sounds like Fil-C combines the ergonomics of C with the performance of Python. It might have a beautiful niche for safely sandboxing legacy code. But I don’t see any compelling reason to use it for new code. Modern GC languages are much more ergonomic than C and better optimised. C#, Java, JavaScript and Go are all easier to write, they have better tooling and they will probably all perform as well or better than Fil-C in its current state.
- jhatemyjob 11mo ago
  [flagged]
  - bigfishrunning 11mo ago
    This is super gross, but I don't see it is relevant... Does java's ecosystem suddenly not solve the same problems it did before?
    - jhatemyjob 11mo ago
      I think it's interesting! Don't you? A fun fact of history most people don't know.
- drnick1 11mo ago
  The ergonomics of C are excellent and the performance seems to be more like Java or C# than Python. The point is that you don't have to rewrite anything, so even the ergonomics of C don't matter.
  - josephg 11mo ago
    > The ergonomics of C are excellent That is a matter of opinion. Personally when I write C, I miss memory safety. And thread safety. I miss non-nullable types. I miss having a good way to return results. And generics. And tuples. And real enums (sum types). I miss having a sane build system. I miss having IDEs that just work with my projects. I miss having a well designed standard library. I miss being able to hit build and have it more or less work on every OS. I miss having a good package manager. And a sane macro language. I wish I didn't need to write header files. And I wish my header files didn't need to be parsed MxN times. I miss fixed integer types just being built into the language - like u8/u16/u32/... And real strings. And on and on. C compilers are fast and mature, so that's a plus. And C binaries are tiny. I mean, C has aged surprisingly well given the language is 53 years old. But its a really old language. And it shows. I would never use it for a new project, because it seems worse in every way compared to languages like Zig, Odin and Rust. > and the performance seems to be more like Java or C# than Python. Alright, I was exaggerating. But I still don't want my linux workstation to feel like a big java program. > The point is that you don't have to rewrite anything, so even the ergonomics of C don't matter. As I said in another comment, I really agree with this. Fil-C makes a lot of sense to me if the goal is to simply take existing legacy software and recompile it in a more memory safe way. But I don't think that's how the developers see it. I think they want fil-C so rust developers shut up, and they can go back to writing C code forever and ever and ever.

o11c 11mo ago

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 11mo ago
> ... 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 11mo ago
  Exactly right
- deleted 11mo ago
  [deleted]
fulafel 11mo ago
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.

malkia 11mo ago

If Fil-C requires complete recompile of ".c" code how does it deal with calls to the OS - Does it rewrap them (like Go?). I'm bit uncertain here...

o11c 11mo ago
It uses a sandwich; see https://fil-c.org/runtime https://fil-c.org/runtime
- malkia 11mo ago
  Thank you!!!