alt.hn

5/16/2026 at 7:10:08 PM

The Fil-C Optimized Calling Convention

 https://fil-c.org/calling_convention

by pizlonator

5/18/2026 at 7:06:22 PM

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.

by dvt

5/18/2026 at 8:48:33 PM

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.

by ndesaulniers

5/18/2026 at 6:55:22 PM

> 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.

by aniviacat

5/18/2026 at 7:01:33 PM

Mostly. A handful of people have made some very nice contributions though

by pizlonator

5/18/2026 at 7:29:57 PM

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

by rurban

5/19/2026 at 6:20:36 AM

One person who spent 15 years learning and building in the domain. He very much knows what he's doing, what questions to ask, and what machines do.

by rossjudson

5/18/2026 at 8:56:27 PM

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

by jancsika

5/18/2026 at 10:07:00 PM

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

by pizlonator

5/18/2026 at 11:04:19 PM

Something something compile Fil-C to WASM64?

by actionfromafar

5/19/2026 at 1:18:25 AM

I don’t see how that would help

by pizlonator

5/19/2026 at 11:26:54 AM

I guess it is the imaginary security that WebAssembly advocates tend to sell, without telling the part that linear memory segments don't have bounds checking within their internals.

by pjmlp

5/19/2026 at 2:19:31 AM

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.

by codebje

5/18/2026 at 10:16:08 PM

> 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.

by skissane

5/19/2026 at 1:18:02 AM

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 :-)

by pizlonator

5/19/2026 at 6:29:50 AM

From what I understand, on x86 Linux stores a thread-local pointer to its TLS block in %fs. Could that simply be re-used?

https://groups.google.com/g/comp.arch/c/IT2dhS4q2M8?pli=1

by grumbelbart2

5/19/2026 at 12:17:54 PM

Yes it could.

It would require more than zero work. Basically you’d need to unify yolo libc’s internal definition of pthread with libpizlo’s filc_thread

by pizlonator

5/19/2026 at 3:38:59 AM

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?

by vlovich123

5/19/2026 at 3:45:43 AM

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)

by pizlonator

5/19/2026 at 5:10:36 AM

This would be a fun and popular project for the right sort of person

by rao-v

5/20/2026 at 2:51:37 AM

Do you think it’s possible to have fil-c ideas applied to protect unsafe blocks in Rust?

by vlovich123

5/20/2026 at 2:00:50 PM

You’d have to teach rust about Fil-C pointers and their special rules. You’d also have to teach the rust compiler to play nice with the Fil-C GC.

It would be a big change. Probably not backwards compatible with today’s rust.

by pizlonator

5/18/2026 at 6:18:38 PM

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.

by ummonk

5/18/2026 at 7:31:02 PM

EDIT: misread the post! Never mind

by StilesCrisis

5/18/2026 at 7:57:21 PM

You even read the comment you’re responding to? They’re saying no threads.

by turkeyboi

5/18/2026 at 9:06:48 PM

You're right. I can't delete anymore unfortunately

by StilesCrisis

5/18/2026 at 8:00:10 PM

Pretty interesting, but what’s the reason of being for Fil-C?

by tines

5/18/2026 at 10:38:07 PM

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.

by connicpu

5/18/2026 at 10:07:49 PM

There's a whole lot of C and C++ software out there, and Fil-C makes it memory safe, frequently with minimal work.

by carry_bit

5/18/2026 at 10:05:42 PM

Memory safety for existing C and C++ codebase.

by nick__m

5/19/2026 at 11:28:01 AM

Especially in systems where CHERI, MTE, ADI and similar harware isn't available.

by pjmlp