4 ms·

From what I understand some things in Fil-C work "as expected" instead of crashing (e.g. dereferencing a pointer to an out of scope variable will give you the o

From what I understand some things in Fil-C work "as expected" instead of crashing (e.g. dereferencing a pointer to an out of scope variable will give you the old value of that variable), so it won't work as a sanitizer.

1718627440 11mo ago
You can use the built-in sanitizer from your compiler though.
- SkiFire13 11mo ago
  At that point why use Fil-C for this though?
  - 1718627440 11mo ago
    Because you don't want to let it crash in production? Sanitizer for testing Fil-C for shipping.
    - pornel 11mo 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 11mo ago
        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 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 ago
        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 11mo ago
        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 11mo ago
        Fil-C should have a(n on by default) mode where collecting an unfreed allocation is a crash, if it doesn't already.
        pizlonator 11mo ago
        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.
    - SkiFire13 11mo ago
      I think you're missing a bit of context from the parent comments: > Maybe it would be possible to embed Fil-C in a test-suite

1718627440 11mo ago

You can use the built-in sanitizer from your compiler though.

SkiFire13 11mo ago
At that point why use Fil-C for this though?
- 1718627440 11mo ago
  Because you don't want to let it crash in production? Sanitizer for testing Fil-C for shipping.
  - pornel 11mo 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 11mo ago
      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 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 ago
        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 11mo ago
        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 11mo ago
        Fil-C should have a(n on by default) mode where collecting an unfreed allocation is a crash, if it doesn't already.
        pizlonator 11mo ago
        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.
  - SkiFire13 11mo ago
    I think you're missing a bit of context from the parent comments: > Maybe it would be possible to embed Fil-C in a test-suite