A simplified model of Fil-C
47 points by fanf
47 points by fanf
If you have a language with a strong compile-time story, and the compile-time language is the same as the runtime language (for example, Zig), you could use a Fil-C setup for safe compile-time evaluation, even if runtime evaluation is unsafe.
Umm, what?
I'm interested in looking into making Zig's ReleaseSafe, or maybe an additional optimization mode, do the equivalent of Fil-C, but I think this comment is victim of a fundamental misunderstanding. Perhaps the author believes that compile-time code execution in Zig allows arbitrary code execution, but that is simply not the case. You can't pointer reinterpret, make syscalls, or otherwise cause any side effects on the host.
I hope this blogger's understanding is not informed by that hallucinated LLM-generated blog post, that I won't link to, and that no self-respecting person replying to this comment will link to, that implied that Zig code at compile time could run arbitrary code on the host.
Author here. That point is hinting at a language I'd like to see: borrow some of Zig's good ideas around comptime, and then take them further. I want to be able to pointer reinterpret at compile time. I can however predict the obvious outcry of "we can't do that because it would be incredibly unsafe", and that's where we borrow from Fil-C to make it safe. If that means running a GC within the compiler, so be it, but I want the final executable artefact to be close to the metal without such things present.
Obviously Zig is yours to evolve as you see fit. If you look at the Fil-C ideas and want to integrate them as a runtime mode, that's your prerogative as BDFL, and there'll be a bunch of people excited by it. For me personally, I'm happy with the maximally unsafe runtime mode, but I would like to see even more functionality allowed at comptime.
Zig's comptime isn't limited by safety issues. It's limited by determinism, independence from the host, and independence of top level declarations from each other. This is a desirable property of any compile time execution. You don't get these from slapping Fil-C onto compile time code execution. This stuff is table stakes. It boggles the mind that some modern languages intentionally eschew these properties.
Important datapoint: "Pointer reinterpret" means arbitrary integer to pointer conversion, not pointer-to-pointer type conversion
Shadow provenance is also how the Miri and the MiniRust abstract machine is able to round-trip pointer provenance through byte-oriented memory (they also have to deal with byte-granularity provenance).
A cool property of Fil's specific approach (InvisiCaps) that the blog post didn't call out is that you don't need a gross partition between the host (runtime) and guest linear address spaces since the provenance-restricted read/write capability means that the invisible_bytes and address_record allocations can be freely allocated in and interleaved within the same address space as the visible_bytes. Those metadata allocations, along with any other host-level allocations, are inaccessible holes of dark matter in the guest's linear address space as far as the guest is concerned.