From my cursory glance, the real magic (InvisiCaps) appears to be a unique take on fat pointers to track types, access rights, etc. Pretty clever, and the website is a great technical read.
Dig the posters in the background; I just saw Burning Ambition in theaters last week. Up the irons, Earth dog! Ghost opened for Iron Maiden a few years ago; I saw them all together in Oakland.
Are there any examples how to force C/C++ libraries within a Rust build to use Fil-C instead to improve security? Is it just a matter of overriding CC/CXX?
So you just need safe unicode identifiers I guess, fixing the longstanding unicode C11 spec bug, which made identifiers unidentifiable. Restricting to ASCII would be safest. In my rcc compiler I use my libu8ident
It has list of more than 20 optimizations for interpreters, with measured speedups. I'm pretty sure I was looking for something like this 3-5 years ago, but it didn't exist
> Where my_thread is a pointer to the current Fil-C thread, which Fil-C passes around as the first argument in all calls.
Does this just mean you reserve a register for the current thread? In which case you could explain it as a reserved register (like FS used for TLS). Describing it as "passes around as the first argument in all calls" makes it sound inefficientâbut whether it actually is depends on how you implement it.
It is exactly as inefficient as âpassing it around as the first argumentâ implies
Thereâs a speedup to be had by either reserving a GPR or using one of the segment registers
Lots of obvious stuff like this hasnât been done yet! If you want to have the satisfaction of landing speedups then Fil-C is a fun thing you could contribute to :-)
So for interpreted languages with types that are written in C, how is the engine supposed to tell C it already checked all the arg types manually in the interpreter? In other words: it's safe to go ahead and dereference this function and invoke it with these args.
Seems like C technically requires function declarations for every possible signature. That quickly explodes into hundreds or thousands of function declarations in the header and switch statement.
If you have an interpreted language, you don't have a C function corresponding to each language function. You have a C interpreter loop with a "current instruction" pointer. When the current interpreted instruction is a call, you check all the things you need to check, push the current IP to a stack, and set the IP to the first instruction of the function.
C's type checker never sees the interpreted language's functions.
Interesting project in general. I wonder whether it could be adapted to behave reasonably without relying on threading. E.g. run the GC only when *alloc is called.
Can't speak to how everyone else is using it but at my job we run all of our unit tests under Fil-C as part of CI, in addition to the UBASAN, TSAN, and Valgrind pipelines we already had for them.
Great video here by the man himself: https://x.com/filpizlo/status/1976831020566798656
From my cursory glance, the real magic (InvisiCaps) appears to be a unique take on fat pointers to track types, access rights, etc. Pretty clever, and the website is a great technical read.
Dig the posters in the background; I just saw Burning Ambition in theaters last week. Up the irons, Earth dog! Ghost opened for Iron Maiden a few years ago; I saw them all together in Oakland.
Are there any examples how to force C/C++ libraries within a Rust build to use Fil-C instead to improve security? Is it just a matter of overriding CC/CXX?
Wonât work
Canât link Fil-C code to regular C code
And rust uses regular C ABI
You could make it work, if you teach Rust and Fil-C about each other. Nobody has done that (to my knowledge)
> Fil-C is a personal passion project by Filip Pizlo.
Do I understand correctly that this project is based on the work of just one person, Filip Pizlo? If so, that's amazing.
Mostly. A handful of people have made some very nice contributions though
So you just need safe unicode identifiers I guess, fixing the longstanding unicode C11 spec bug, which made identifiers unidentifiable. Restricting to ASCII would be safest. In my rcc compiler I use my libu8ident
I came around to it a few weeks late, but Zef and this article by Filip are also great work!
https://zef-lang.dev/implementation
https://news.ycombinator.com/item?id=47843194
It has list of more than 20 optimizations for interpreters, with measured speedups. I'm pretty sure I was looking for something like this 3-5 years ago, but it didn't exist
> Where my_thread is a pointer to the current Fil-C thread, which Fil-C passes around as the first argument in all calls.
Does this just mean you reserve a register for the current thread? In which case you could explain it as a reserved register (like FS used for TLS). Describing it as "passes around as the first argument in all calls" makes it sound inefficientâbut whether it actually is depends on how you implement it.
It is exactly as inefficient as âpassing it around as the first argumentâ implies
Thereâs a speedup to be had by either reserving a GPR or using one of the segment registers
Lots of obvious stuff like this hasnât been done yet! If you want to have the satisfaction of landing speedups then Fil-C is a fun thing you could contribute to :-)
So for interpreted languages with types that are written in C, how is the engine supposed to tell C it already checked all the arg types manually in the interpreter? In other words: it's safe to go ahead and dereference this function and invoke it with these args.
Seems like C technically requires function declarations for every possible signature. That quickly explodes into hundreds or thousands of function declarations in the header and switch statement.
Edit: clarification
If you have an interpreted language, you don't have a C function corresponding to each language function. You have a C interpreter loop with a "current instruction" pointer. When the current interpreted instruction is a call, you check all the things you need to check, push the current IP to a stack, and set the IP to the first instruction of the function.
C's type checker never sees the interpreted language's functions.
Iâve thought about how to let folks prove to Fil-C that Fil-Câs checks are obviated by some higher level checks.
Itâs a super hard problem! I donât have a good answer, but I also canât prove that itâs impossible
Something something compile Fil-C to WASM64?
I donât see how that would help
Interesting project in general. I wonder whether it could be adapted to behave reasonably without relying on threading. E.g. run the GC only when *alloc is called.
EDIT: misread the post! Never mind
You even read the comment youâre responding to? Theyâre saying no threads.
You're right. I can't delete anymore unfortunately
Pretty interesting, but whatâs the reason of being for Fil-C?
Can't speak to how everyone else is using it but at my job we run all of our unit tests under Fil-C as part of CI, in addition to the UBASAN, TSAN, and Valgrind pipelines we already had for them.
There's a whole lot of C and C++ software out there, and Fil-C makes it memory safe, frequently with minimal work.
Memory safety for existing C and C++ codebase.