I think the issue with this approach is it’s perfectly reasonable in Fil-C to never call `free` because the GC will GC. So if you develop on Fil-C, you may be leaking memory if you run in production with Yolo-C.

▲

pornel 2 days ago | parent [-]

Fil-C uses `free()` to mark memory as no longer valid, so it is important to keep using manual memory management to let Fil-C catch UAF bugs (which are likely symptoms of logic bugs, so you'd want to catch them anyway).

The whole point of Fil-C is having C compatibility. If you're going to treat it as a deployment target on its own, it's a waste: you get overhead of a GC language, but with clunkiness and tedium of C, instead of nicer language features that ground-up GC languages have.

▲

jacquesm 2 days ago | parent [-]

I agree with you but jitl has a point: implicit reliance on the GC could creep in and you might not notice it until you switch back to regular C.

▲

estebank 2 days ago | parent [-]

Fil-C should have a(n on by default) mode where collecting an unfreed allocation is a crash, if it doesn't already.

	▲	pizlonator 2 days ago \| parent [-]
		It's not that simple since some object allocations go unfreed. For example, Fil-C lifts all escaping locals to the heap, but doesn't free them.