6 ms·
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 l
by jitl 11mo ago
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 11mo agoFil-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 11mo agoI 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 11mo agoFil-C should have a(n on by default) mode where collecting an unfreed allocation is a crash, if it doesn't already.
- pizlonator 11mo agoIt'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.