[HN Gopher] Using the GCC Static Analyzer on the D Programming L...
       ___________________________________________________________________
        
       Using the GCC Static Analyzer on the D Programming Language
        
       Author : pabs3
       Score  : 98 points
       Date   : 2022-03-05 11:25 UTC (11 hours ago)
        
 (HTM) web link (dlang.org)
 (TXT) w3m dump (dlang.org)
        
       | synergy20 wrote:
       | what is the difference between a sanitizer and analyzer in gcc?
        
         | synergy20 wrote:
         | replying my own question: analyzer at compiler time(thus
         | static), sanitizer at runtime.
        
       | gavinray wrote:
       | It was really neat to see the example of the analyzers ability to
       | find issues in cross-language sources (IE D code mixed with C/C++
       | sources). I didn't know it could do this.
       | 
       | Thanks for writing this =)
        
       | buserror wrote:
       | I tried the -fanalyser recently with a piece of C code. OMG.
       | pages and pages and pages of "possible-NULL" and other
       | "c/m/realloc(...) could return NULL!". Really, if I'm in a
       | situation where *alloc() returns NULL, I'm happy for the program
       | to SIGBUS, the machine is probably in a sorry state and there's
       | no safe "software" path that would make it all magically better.
       | 
       | The clang analyser, or cppcheck is a LOT more pragmatic about
       | these things. the gcc one is SO noisy as to make it useless at
       | the minute, TBH.
       | 
       | Disclaimer: I'm actually a fan of gcc!
        
         | pm215 wrote:
         | If you want "malloc failure is fatal", which I agree is a good
         | idea for a lot of programs, the way to do that is have a
         | wrapper that aborts() if it does, not to just ignore the
         | possibility of error. That way if the unlikely event ever does
         | happen you get an immediate and clear failure, rather than a
         | NULL which might eventually some time later get dereferenced,
         | so if you get a user crash report you don't ever have to spend
         | time debugging "why did this NULL get here in this data
         | structure? was it maybe a memory corruption bug?".
         | 
         | It also means that if you're dealing with untrusted input you
         | have a guard against that data provoking a huge malloc that
         | fails and manages to do something unexpected as a result. Sure,
         | most of the time the "something unexpected" isn't interesting
         | (immediate crash), and there probably ought to have been a
         | range-check on the input data already, but the NULL-check-and-
         | abort means you never have to spend any time thinking about
         | whether the code is the 0.1% "interestingly exploitable" case.
         | Not having to think about a whole class of situations is pretty
         | valuable IME.
        
       | mhh__ wrote:
       | I wrote this article (not the Analyzer, that was David Malcolm -
       | worship him)
       | 
       | Any questions about D or the specifics of this article or the
       | Analyzer, fire away.
        
       | Simon_O_Rourke wrote:
       | Does it help in any way with designing a better garbage
       | collector?
        
         | mhh__ wrote:
         | Not really.
         | 
         | Statically verifying a GC is probably the kind of thing you
         | want to specify in TLA+ whereas this basically only infers
         | corruption on "local" memory i.e. as opposed abstract memory
         | being managed by a GC
        
       ___________________________________________________________________
       (page generated 2022-03-05 23:00 UTC)