6 ms·

> it seems impossible to secure c or c++ False. Fil-C secures C and C++. It’s more comprehensively safe than Rust (Fil-C has no escape hatches). And it’s compa

> it seems impossible to secure c or c++ False. Fil-C secures C and C++. It’s more comprehensively safe than Rust (Fil-C has no escape hatches). And it’s compatible enough with C/C++ that you can think of it as an alternate clang target.

nzeid 1y ago
I love this shameless self-promotion. ;) Fil-C is in the cards for my next project.
- pizlonator 1y ago
  Thank you for considering it :-) Hit me up if you have questions or issues. I’m easy to find
  - 90s_dev 1y ago
    One of these days, a project will catch on that's vastly simpler than any memory solution today, yet solves all the same problems, and more robustly too, just like how it took humanity thousands of years to realize how to use levers to build complex machines. The solution is probably sitting right under our noses. I'm not sure it's your project (maybe it is) but I bet this will happen.
    - pizlonator 1y ago
      That’s a really great attitude! And I think you’re right! I think in addition to possibly being the solution to safety for someone, Fil-C is helping to elucidate what memory safe systems programming could look like and that might lead to someone building something even better
  - deleted 1y ago
    [deleted]
Ygg2 1y ago
> It's more comprehensively safe than Rust Yeah. By adding a runtime. > Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space) https://github.com/pizlonator/llvm-project-deluge/tree/deluge https://github.com/pizlonator/llvm-project-deluge/tree/delug...
- pizlonator 1y ago
  > Yeah. By adding a runtime. So? That doesn't make it any less safe or useful. In almost all uses of C and C++, the language already has a runtime. In the Gnu universe, it's the combination of libgcc, the loader, the various crt entrypoints, and libc. In the Apple version, it's libcompiler_rt and libSystem. Fil-C certainly adds more to the runtime, but it's not like there was no runtime before.
  - jandrewrogers 1y ago
    It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.
    - dustbunny 1y ago
      > a lot less performant Is this just you speculating? How much is "a lot"? Where's the data? Let's get some benchmarks!
      - pizlonator 1y ago
        I mean bro isn’t totally wrong. Fil-C’s perf sucks on some workloads. And it doesn’t suck on others. Extreme examples to give you an idea: - xzutils had about 1.2x overhead. So slower but totally usable. - no noticeable overhead in shells, systems utilities, ssh, curl, etc. But that’s because they’re IO bound. - 4x or sometimes maybe even higher overheads for things like JS engines, CPython, Lua, Tcl, etc. Also OpenSSL perf tests are around 4x I think. But you’re on thin ice if you say that this is a reason why Fil-C will fail. So much of Fil-C’s overhead is due to known issues that I will fix eventually, like the function call ABI (which is hella cheesy right now because I just wanted to have something that works and haven’t actually made it good yet).
NIckGeek 1y ago
Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency. Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime knowledge.
- pizlonator 1y ago
  Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`. Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)
  - NIckGeek 1y ago
    > but in practice fails, because of pervasive use of `unsafe`. Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs. I'm aware C already has a runtime, this adds to it.
    - pizlonator 1y ago
      > Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs. Those are the excuses I heard from C++ programmers for years. Memory safety is about guarantees enforced by the compiler. `unsafe` isn't that.
  - deleted 1y ago
    [deleted]
  - Rusky 1y ago
    The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it. Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.

nzeid 1y ago

I love this shameless self-promotion. ;) Fil-C is in the cards for my next project.

pizlonator 1y ago
Thank you for considering it :-) Hit me up if you have questions or issues. I’m easy to find
- 90s_dev 1y ago
  One of these days, a project will catch on that's vastly simpler than any memory solution today, yet solves all the same problems, and more robustly too, just like how it took humanity thousands of years to realize how to use levers to build complex machines. The solution is probably sitting right under our noses. I'm not sure it's your project (maybe it is) but I bet this will happen.
  - pizlonator 1y ago
    That’s a really great attitude! And I think you’re right! I think in addition to possibly being the solution to safety for someone, Fil-C is helping to elucidate what memory safe systems programming could look like and that might lead to someone building something even better
- deleted 1y ago
  [deleted]

Ygg2 1y ago

> It's more comprehensively safe than Rust Yeah. By adding a runtime. > Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (each pointer in memory has a corresponding capability, not visible to the C address space) https://github.com/pizlonator/llvm-project-deluge/tree/deluge https://github.com/pizlonator/llvm-project-deluge/tree/delug...

pizlonator 1y ago
> Yeah. By adding a runtime. So? That doesn't make it any less safe or useful. In almost all uses of C and C++, the language already has a runtime. In the Gnu universe, it's the combination of libgcc, the loader, the various crt entrypoints, and libc. In the Apple version, it's libcompiler_rt and libSystem. Fil-C certainly adds more to the runtime, but it's not like there was no runtime before.
- jandrewrogers 1y ago
  It makes it a lot less performant and there is no avoiding or mitigating that downside. C++ is often selected as a language instead of safer options for its unusual performance characteristics even among systems languages in practice. Fil-C is not a replacement for C++ generally, that oversells it. It might be a replacement for some C++ software without stringent performance requirements or a rigorously performance-engineered architecture. There is a lot of this software, often legacy.
  - dustbunny 1y ago
    > a lot less performant Is this just you speculating? How much is "a lot"? Where's the data? Let's get some benchmarks!
    - pizlonator 1y ago
      I mean bro isn’t totally wrong. Fil-C’s perf sucks on some workloads. And it doesn’t suck on others. Extreme examples to give you an idea: - xzutils had about 1.2x overhead. So slower but totally usable. - no noticeable overhead in shells, systems utilities, ssh, curl, etc. But that’s because they’re IO bound. - 4x or sometimes maybe even higher overheads for things like JS engines, CPython, Lua, Tcl, etc. Also OpenSSL perf tests are around 4x I think. But you’re on thin ice if you say that this is a reason why Fil-C will fail. So much of Fil-C’s overhead is due to known issues that I will fix eventually, like the function call ABI (which is hella cheesy right now because I just wanted to have something that works and haven’t actually made it good yet).

NIckGeek 1y ago

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency. Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime knowledge.

pizlonator 1y ago
Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`. Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)
- NIckGeek 1y ago
  > but in practice fails, because of pervasive use of `unsafe`. Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs. I'm aware C already has a runtime, this adds to it.
  - pizlonator 1y ago
    > Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs. Those are the excuses I heard from C++ programmers for years. Memory safety is about guarantees enforced by the compiler. `unsafe` isn't that.
- deleted 1y ago
  [deleted]
- Rusky 1y ago
  The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it. Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.