Mixing safe and unsafe

Posted Oct 31, 2025 17:24 UTC (Fri) by epa (subscriber, #39769)
In reply to: Mixing safe and unsafe by matthias
Parent article: Fil-C: A memory-safe C implementation

You make a good point, but the same applies to ordinary C code. In unchecked C you immediately have undefined behaviour if there are invalid pointers in a linked list. And so on. It's surely easier for the programmer to worry about all these nasty problems in just 5% of the code than in all of it.

You have to verify that the unsafe block is never called with violated invariants,

I didn't quite understand this point. You do have to verify that -- but surely to do so it's enough to prove that all unsafe blocks in your program are behaving nicely? If the unsafe blocks are correct, then the other 95% of the code (the "safe" part) will not violate any invariants -- or at least if it does so, the program will blow up at run time as soon as it happens. (Fil-C does not claim to give you the same thorough compile-time checking as Rust.)

to post comments

Mixing safe and unsafe

Posted Oct 31, 2025 18:27 UTC (Fri) by matthias (subscriber, #94967) [Link] (1 responses)

> If the unsafe blocks are correct, then the other 95% of the code (the "safe" part) will not violate any invariants -- or at least if it does so, the program will blow up at run time as soon as it happens.

This is the way rust works, but not how Fil-C works. Fil-C checks the pointers when they are used. It does not check at compile time (that is what rust does with references) and it cannot check when they are constructed. A pointer can alias with an integer type. So you can write any value into the pointer and Fil-C will not complain. It will only complain when you try to use the pointer and the metadata is incorrect. If the first use of an invalid pointer is in the unsafe code and you have turned off the runtime checks in this part of the code then you have UB.

Once you turn off the runtime checks in any part of the code, you have to verify all code for correctness that touches the same memory as the unsafe code.

Mixing safe and unsafe

Posted Nov 1, 2025 15:02 UTC (Sat) by epa (subscriber, #39769) [Link]

Thanks, I understand now. So you’d have to prove that any pointers used within the unsafe block were valid pointers — a property not enforced in advance of using them, even by safe code.

Despite that drawback, I still feel that a mixed model with mostly safe code and a few unsafe hotspots would be more productive than doing everything in unsafe C, and might be fast enough when 100% safe Fil-C is too slow.