Conversation

Notices

1. Embed this notice
   Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 26-Apr-2024 04:25:59 JST Haelwenn /элвэн/ :triskell:
   > try the static analyzer of gcc
   > spews a whole bunch of bullshit
   
   LLVM Static Analyzer is really the only good one out there.
   • Embed this notice
     *(*(void **(*)()) lizzy)() :v_trans: :v_bi: (fleckenstein@social.lizzy.rs)'s status on Friday, 26-Apr-2024 13:37:03 JST *(*(void **(*)()) lizzy)() :v_trans: :v_bi:

     in reply to

     • anna

     @navi @lanodan i somehow also get a bunch of BS results every time, while you don't get them with the same code, it's really weird and obscure

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     anna (navi@social.vlhl.dev)'s status on Friday, 26-Apr-2024 13:37:05 JST anna

     in reply to
     @lanodan clang's analyzer is unusable for me because of the stupid way they implemented it, as a separate step that can't be done *during* compilation
     
     meaning i would need to remember to run it, then go to my browser to view it, while gcc runs during the build, and has a nice output right there on the terminal
     
     (tho i've also didn't get bs results from gcc yet, but ig i never used it in a really complex codebase)
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 26-Apr-2024 13:40:25 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • anna
     @navi Yeah, I wish it would be a flag like with gcc, would be so much easier to use, which is why I wanted to see how gcc does…
     As for the output, I actually quite prefer having it in a separated file given how you can quite easily end up with 15+ steps.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Friday, 26-Apr-2024 14:11:13 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • anna
     • *(*(void **(*)()) lizzy)() :v_trans: :v_bi:
     @fleckenstein @navi Here it seems to be mostly reproducible at least.
     
     By the way here's what I got from it:
     - Claims fd leak with dup2, I guess expecting me to close fildes2 while dup2 *expects* to be the one closing fildes2 as it returns -1 if it fails to close or if it isn't valid
     - Claims a leak of FILE, that one I could see why it happens… (list of arguments to open them, same list of arguments to close them, instead of say looping on the array of opened files, which hopefully it would then analyze correctly)
     - (non-reproducible) Claims an invalid fd getting passed, even though it's when open returns 'fd > 0' which by definition is valid (negative fd being invalid)
     
     And no other claims so all were invalid. (That said, I fixed everything but dead increments from llvm/clang static analyzer).