6 ms·

Or you could use Fil-C++ and get memory safety without any changes. Unlike this proposal, fil-C++ can run real C and C++ programs safely today (including intere

Or you could use Fil-C++ and get memory safety without any changes. Unlike this proposal, fil-C++ can run real C and C++ programs safely today (including interesting stuff like CPython, OpenSSH, and SQLite). I don’t buy that adding an extension that is safe if you use it will move the needle. But making the language safe wholesale is practical. We should do that instead.

Svoka 2y ago
sorry, what's Fil-C++?
- nneonneo 2y ago
  His pet project, a garbage-collected variant of C++: https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-C-memory-safety-with-fanatical-C-C-compatibility https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-...
- orion138 2y ago
  I think it’s this: https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-C-memory-safety-with-fanatical-C-C-compatibility https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-... https://github.com/pizlonator/llvm-project-deluge/blob/deluge/Manifesto.md https://github.com/pizlonator/llvm-project-deluge/blob/delug...
  - pizlonator 2y ago
    Yes. More info: https://www.youtube.com/watch?v=xR8y7swDkPU https://www.youtube.com/watch?v=xR8y7swDkPU https://www.youtube.com/watch?v=JRoX9_lXJFg https://www.youtube.com/watch?v=JRoX9_lXJFg
felipefar 2y ago
Hard pass on the garbage collector. We don't need that, and the minimal GC support that was in the standard has been removed from C++23.
- pizlonator 2y ago
  > Hard pass on the garbage collector. Why? > We don't need that You do if you want comprehensive use-after-free protection. > and the minimal GC support that was in the standard has been removed from C++23. Not related to what I'm doing. The support you cite is for users of the language to write garbage collectors "on top" of the language. Fil-C++'s garbage collector is hidden in the implementation's guts, "below" the language. Fil-C++ is compliant to C++ whether C++ says that GC is allowed or not.
  - felipefar 2y ago
    They solve the use-after-free issue by keeping pointed objects alive, not by helping you think better about object lifetimes in your code. That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. Added to that, they also introduce random, unpredictable slowdowns in your application to run their algorithms. I'm not yet sold on Rust, but exploring alternatives for achieving memory safety without needing to put on a GC is commendable.
    - pizlonator 2y ago
      > They solve the use-after-free issue by keeping pointed objects alive That's not at all what Fil-C's garbage collector does. If you free() an object in Fil-C, then the capability is marked free and the next GC cycle will: - Delete the object. - Repoint all capabilities that referred to that object to point to the free singleton capability instead. This ensures that: - Freeing an object really does free it, regardless of whether the GC sees it as reachable. - Using an object after freeing it is guaranteed to trap with a Fil-C panic, and that panic is guaranteed to report that the object has been freed so you know why you're trapping. Also, as a bonus, if you don't ever free your objects, then the Fil-C GC will delete them for you once they become unreachable. So, you can write Java-style code in C++, if you want. > That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. No idea what you mean there. Maybe you're thinking of reference counting, which isn't a form of garbage collection. (Reference counting is different precisely because it cannot handle cycles.) > unpredictable slowdowns in your application to run their algorithms. Fil-C's garbage collector is 100% concurrent. It'll never pause your shit.
gmueckl 2y ago
From the github README: > On the other hand, Fil-C is quite slow. It's ~10x slower than legacy C right now (ranging from 3x slower in the best case, xz decompress, to 20x in the worst case, CPython). That performance loss is severe and makes the approaches totally uninteresting for a most serious use cases. Most applications written in C or C++ don't get to waste that many cycles.
- pizlonator 2y ago
  Those are old perf numbers. It’s sub-2x most of the time now, and I’m working on optimizations to make it even faster. Note that at the start of this year it was 200x slower. I land speed ups all the time but don’t always update the readme every time I land an optimization. Perf is the main focus of my work on Fil-C right now.
  - Krutonium 2y ago
    Might I suggest having the CI benchmark it and then update the readme?
    - pizlonator 2y ago
      If I had the time to set that up then yeah. Right now I’m spending all my time actually implementing optimizations and measuring them locally. I did spend the time to give myself a good benchmark suite with a nice harness (I call it PizBench, it includes workloads from xzutils, simdutf, Python, OpenSSL, and others).
elliotpotts 2y ago
Wow, Fil-C++ looks very interesting! I wonder what % of programs make its pointer tracking fail due to stuffing things in the higher bits, doing integer conversions and so on. It reminds me of CHERI.
- pizlonator 2y ago
  You can put stuff in the high and low bits of pointers in Fil-C so long as you clear them before access, otherwise the access itself traps. Python does shit like that and it works fine in Fil-C, though I needed to make some minor adjustments a like a 50KB ish patch to CPython.

Svoka 2y ago

sorry, what's Fil-C++?

nneonneo 2y ago
His pet project, a garbage-collected variant of C++: https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-C-memory-safety-with-fanatical-C-C-compatibility https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-...
orion138 2y ago
I think it’s this: https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-C-memory-safety-with-fanatical-C-C-compatibility https://2024.splashcon.org/details/splash-2024-rebase/3/Fil-... https://github.com/pizlonator/llvm-project-deluge/blob/deluge/Manifesto.md https://github.com/pizlonator/llvm-project-deluge/blob/delug...
- pizlonator 2y ago
  Yes. More info: https://www.youtube.com/watch?v=xR8y7swDkPU https://www.youtube.com/watch?v=xR8y7swDkPU https://www.youtube.com/watch?v=JRoX9_lXJFg https://www.youtube.com/watch?v=JRoX9_lXJFg

felipefar 2y ago

Hard pass on the garbage collector. We don't need that, and the minimal GC support that was in the standard has been removed from C++23.

pizlonator 2y ago
> Hard pass on the garbage collector. Why? > We don't need that You do if you want comprehensive use-after-free protection. > and the minimal GC support that was in the standard has been removed from C++23. Not related to what I'm doing. The support you cite is for users of the language to write garbage collectors "on top" of the language. Fil-C++'s garbage collector is hidden in the implementation's guts, "below" the language. Fil-C++ is compliant to C++ whether C++ says that GC is allowed or not.
- felipefar 2y ago
  They solve the use-after-free issue by keeping pointed objects alive, not by helping you think better about object lifetimes in your code. That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. Added to that, they also introduce random, unpredictable slowdowns in your application to run their algorithms. I'm not yet sold on Rust, but exploring alternatives for achieving memory safety without needing to put on a GC is commendable.
  - pizlonator 2y ago
    > They solve the use-after-free issue by keeping pointed objects alive That's not at all what Fil-C's garbage collector does. If you free() an object in Fil-C, then the capability is marked free and the next GC cycle will: - Delete the object. - Repoint all capabilities that referred to that object to point to the free singleton capability instead. This ensures that: - Freeing an object really does free it, regardless of whether the GC sees it as reachable. - Using an object after freeing it is guaranteed to trap with a Fil-C panic, and that panic is guaranteed to report that the object has been freed so you know why you're trapping. Also, as a bonus, if you don't ever free your objects, then the Fil-C GC will delete them for you once they become unreachable. So, you can write Java-style code in C++, if you want. > That means some objects will live for longer than you initially thought they would, and potentially even introduce circular references. No idea what you mean there. Maybe you're thinking of reference counting, which isn't a form of garbage collection. (Reference counting is different precisely because it cannot handle cycles.) > unpredictable slowdowns in your application to run their algorithms. Fil-C's garbage collector is 100% concurrent. It'll never pause your shit.

gmueckl 2y ago

From the github README: > On the other hand, Fil-C is quite slow. It's ~10x slower than legacy C right now (ranging from 3x slower in the best case, xz decompress, to 20x in the worst case, CPython). That performance loss is severe and makes the approaches totally uninteresting for a most serious use cases. Most applications written in C or C++ don't get to waste that many cycles.

pizlonator 2y ago
Those are old perf numbers. It’s sub-2x most of the time now, and I’m working on optimizations to make it even faster. Note that at the start of this year it was 200x slower. I land speed ups all the time but don’t always update the readme every time I land an optimization. Perf is the main focus of my work on Fil-C right now.
- Krutonium 2y ago
  Might I suggest having the CI benchmark it and then update the readme?
  - pizlonator 2y ago
    If I had the time to set that up then yeah. Right now I’m spending all my time actually implementing optimizations and measuring them locally. I did spend the time to give myself a good benchmark suite with a nice harness (I call it PizBench, it includes workloads from xzutils, simdutf, Python, OpenSSL, and others).

elliotpotts 2y ago

Wow, Fil-C++ looks very interesting! I wonder what % of programs make its pointer tracking fail due to stuffing things in the higher bits, doing integer conversions and so on. It reminds me of CHERI.

pizlonator 2y ago
You can put stuff in the high and low bits of pointers in Fil-C so long as you clear them before access, otherwise the access itself traps. Python does shit like that and it works fine in Fil-C, though I needed to make some minor adjustments a like a 50KB ish patch to CPython.