Yes, Fil-C uses some kind of garbage collector. But it can still detect use-after-free: In the 'free' call, the object is marked as free. In the garbage collection (in the mark phase), if a reference is detected to an object that was freed, then the program panics. Sure, it is also possible to simply ignore the 'free' call - in which case you "just" have a memory leak. I don't think that's what Fil-C does by default however. (This would be more like the behavior of the Boehm GC library for C, if I understand correctly.)

▲

jitl 2 days ago | parent | next [-]

I don’t think that’s how it works. Once an object is freed, any access will crash. You’re allowed to still have a reference to it.

	▲	thomasmg 2 days ago \| parent [-]
		Ok, you are right. My point is, yes it is possible to panic on use-after-free with Fil-C. With Fil-C, a life reference to a freed object can be detected.

▲

cyberax 2 days ago | parent | prev [-]

A free()-d object that is NOT garbage-collected during the next collection is a bug in itself.

▲

pizlonator 2 days ago | parent | next [-]

The Fil-C GC will only GC a free'd object if it succeeds at repointing all capabilities to it to point at the free singleton instead.

Don't worry, it's totally sound.

▲

thomasmg 2 days ago | parent | prev [-]

I'm not sure what you mean. Do you mean there is a bug _in the garbage collection algorithm_, if the object is not freed in the very next garbage collection cycle? Well, it depends: the garbage collection could defers collection of some objects until memory is low. Multi-generation garbage collection algorithm often do this.

	▲	cyberax a day ago \| parent [-]
		You can defer the actual freeing of the object until at least one GC pass finishes. Then alert if any of them are still reachable.