| ▲ | pornel 2 days ago | ||||||||||||||||||||||||||||||||||
Fil-C will crash on memory corruption too. In fact, its main advantage is crashing sooner. All the quick fixes for C that don't require code rewrites boil down to crashing. They don't make your C code less reliable, they just make the unreliability more visible. To me, Fil-C is most suited to be used during development and testing. In production you can use other sandboxing/hardening solutions that have lower overhead, after hopefully shaking out most of the bugs with Fil-C. | |||||||||||||||||||||||||||||||||||
| ▲ | jacquesm 2 days ago | parent | next [-] | ||||||||||||||||||||||||||||||||||
The great thing about such crashes is if you have coredumps enabled that you can just load the crashed binary into GDB and type 'where' and you most likely can immediately figure out from inspecting the call stack what the actual problem is. This was/is my go-to method to find really hard to reproduce bugs. | |||||||||||||||||||||||||||||||||||
| ▲ | jitl 2 days ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||
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. | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||