Announcement

Collapse
No announcement yet.

GCC's New Static Analysis Capabilities Are Getting Into Shape For GCC 10

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC's New Static Analysis Capabilities Are Getting Into Shape For GCC 10

    Phoronix: GCC's New Static Analysis Capabilities Are Getting Into Shape For GCC 10

    One of many new features in the GCC 10 code compiler releasing in about one month's time is finally having a built-in static analyzer. This static analyzer can be enabled with the -fanalyzer switch and has been maturing nicely for its initial capabilities in the GNU Compiler Collection 10...

    http://www.phoronix.com/scan.php?pag...Analyzer-State

  • #2
    Great!

    Comment


    • #3
      I hate how these import changes to the core infrastructure of the entire open source eco system does not get much discussion and light.
      Great job!

      Comment


      • #4
        How about MISRA rules checks? That one makes C far safer and provokes far better code quality - at which point it can improve code security, stability and reliability a lot.

        Comment


        • #5
          Originally posted by SystemCrasher View Post
          How about MISRA rules checks? That one makes C far safer and provokes far better code quality
          safer c with better code quality is produced by isocpp.org
          and misra is garbage
          From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams' observation that all modifications have a non-zero probability of introducing a fault, this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable.
          Last edited by pal666; 03-29-2020, 12:04 PM.

          Comment


          • #6
            i'm worried that subj ignores standard everyone else is implementing
            https://devblogs.microsoft.com/cppbl...019-preview-2/
            https://llvm.org/devmtg/2019-04/slid...s_Lifetime.pdf

            Comment


            • #7
              Originally posted by pal666 View Post
              safer c with better code quality is produced by isocpp.org
              To the hell with C++, IMHO. Especially in embedded environments and somesuch. C++ got far more complicated runtime environment and far more complicated interactions. This implies it far less predictable tool either. Maybe it not a huge problem in some mediocre crappy program or network service, after all what the worst could happen if it fails? However, it sucks a lot if something like this happens in e.g. realtime control and automation, MCU firmwares and so on. To extent it can get just plain dangerous or hard to predict. Well, even C could be quite a bitch if you need it to be really predictable and failure isn't option like in MCU firmwares dealing with safety-critical realtime stuff. My personal opinion is that keeping things like that dead simple and applying heavy testing is best, in terms of stability, reliability and predictability of the result.

              MISRA makes C somewhat less bitchy in safety-critical applications - and quite some MISRA rules _do_ look reasonable, being pretty good known places where C ppl often shots their legs. And therefore, these places are good to avoid, unless there is truly compelling reasons to do otherwise.
              So before posing some valuable opinions about this topic it could make sense to:
              1) Read these rules.
              2) Use your brain.
              3) Evaluate how do these rules improve overall code behavior if you need something that would be really predictable.

              Just in case, MCU ppl sometimes even consider truly arcane failure modes like e.g. "program counter runaway" and other strange crap like sudden control flow faults, sudden data faults, sudden HW faults and so on (that's not my invention, just some MCU firmware coding appnotes). C is relatively straightforward - at which point it gives at least some chance to try to dodge even these bullets in anyhow meaningful ways. Have fun trying it with C++, where syntactic sugar and powerful features often come at cost of simplicity and predictability.

              And speaking of myself last thing I may want in, say, car's ECU is some batshit C++ firmware compiled using MS VS. That could surely make world far more dangerous place to live in. Killing hell a lot of people in some strange accidents.
              Last edited by SystemCrasher; 03-29-2020, 06:45 PM.

              Comment


              • #8
                Originally posted by SystemCrasher View Post
                How about MISRA rules checks? That one makes C far safer and provokes far better code quality - at which point it can improve code security, stability and reliability a lot.
                MISRA is a mixture of common sense rules and unmitigated crap opinion. That said, compliance is a fundamental requirement of safety certification.

                I don't think weaving MISRA into GCC by default is a worthwhile effort, mostly because it costs a corporate-level investment to buy the temporary right to know the MISRA rules (any implementation of them would not be GPL-compatible). Any large corporate enterprise that can afford the license fees to be able to legally think about MISRA can also afford one of the many commercial products out there that specialize in MISRA compliance checking and in keeping with the usual practice, those commercial suppliers can be prosecuted in the event of liability. In the world of safety-critical software development, lawyers play a crucial role.

                I think the best course of action for GCC is to have its static checker be extensible through customizable rulesets. Third parties can provide a licensed MISRA ruleset, and GCC shops can provide house-rules stylecheckers. Everyone goes home happy.

                Comment


                • #9
                  Originally posted by SystemCrasher View Post
                  C++ got far more complicated runtime environment and far more complicated interactions. This implies it far less predictable tool either.
                  it's much more predictable than "don't forget to call free correct number of times". and it's runtime environment is simple enough to be used on arduinos(granted, that's subset of c++, but not subset of c)
                  Originally posted by SystemCrasher View Post
                  Maybe it not a huge problem in some mediocre crappy program or network service, after all what the worst could happen if it fails?
                  you seem to be very experienced writer of mediocre programs. c++ in the meantime flies to mars
                  Originally posted by SystemCrasher View Post
                  My personal opinion is that keeping things like that dead simple and applying heavy testing is best, in terms of stability, reliability and predictability of the result.
                  your personal opinion is garbage. humans shouldn't do stupid error-prone work like every c programmer does
                  Originally posted by SystemCrasher View Post
                  So before posing some valuable opinions about this topic it could make sense to:
                  1) Read these rules.
                  2) Use your brain.
                  3) Evaluate how do these rules improve overall code behavior if you need something that would be really predictable.
                  i read these rules(misra c++ that is - you see, even misra blessed real language to use instead of c). i wasn't excited. the best way to improve overall code behavior is to ignore misra and use c++ core guidelines. and unlike you i substantiated my valuable opinion with quote from study which found misra harmful
                  Originally posted by SystemCrasher View Post
                  Just in case, MCU ppl sometimes even consider truly arcane failure modes like e.g. "program counter runaway" and other strange crap like sudden control flow faults, sudden data faults, sudden HW faults and so on (that's not my invention, just some MCU firmware coding appnotes). C is relatively straightforward - at which point it gives at least some chance to try to dodge even these bullets in anyhow meaningful ways. Have fun trying it with C++, where syntactic sugar and powerful features often come at cost of simplicity and predictability.
                  syntactic sugar and powerful features of c++ are opt-ins. developer decides when to use them. without c++ developer either can't use them when they are beneficial, or has to invent some macro horrors which are much less simple or predictable
                  Originally posted by SystemCrasher View Post
                  And speaking of myself last thing I may want in, say, car's ECU is some batshit C++ firmware compiled using MS VS. That could surely make world far more dangerous place to live in. Killing hell a lot of people in some strange accidents.
                  what makes you happy to kill people with your batshit c firmware?
                  Last edited by pal666; 03-30-2020, 03:41 PM.

                  Comment


                  • #10
                    Originally posted by bregma View Post
                    MISRA is a mixture of common sense rules and unmitigated crap opinion. That said, compliance is a fundamental requirement of safety certification
                    I've actually read most MISRA C rules (not C++, to the hell with it, IMHO). I found plenty of them reasonable and trying hard to stick to most of them when coding MCU firmware for the sake of predictability, even if it isn't formal requirement or so. Safety certifications haven't appeared for fun - they are written in blood, that's how we learned them. pal666 showcases us why keeping incompetent persons away from critical code is important.

                    So MISRA rules are very useful if you want something stable, predictable, "should never fail" kind of thing like MCU firmware. But yes, some demands look crazy unless you're equally crazy about system safety, reliability and predictable behavior and doing embedded engineering right. Sure, sometimes they are inconvenient. Still, I prefer to stay on this side when in doubt. Its good for firmware safety and predictability.

                    I don't think weaving MISRA into GCC by default is a worthwhile effort, mostly because it costs a corporate-level investment to buy the temporary right to know the MISRA rules (any implementation of them would not be GPL-compatible).
                    I do think MISRA shot their legs a lot with their approach - yet their rules on their own aren't secret or something. What proprietary is _text_ of rules, put in error messages. Yet, I think it fine to just spit "MISRA rule X is violated" warning, unless someone provides actual messages. Some opensource static analyzers do it like this. The problem is that these are independent of compiler and their overall quality is well below of e.g. GCC.

                    In the world of safety-critical software development, lawyers play a crucial role.
                    I've seen some opensource MISRA checkers. Well, they obviously dont contain full MISRA rules text for IP reasons. Yet I think that's where MISRA should reconsider their approach.

                    I think the best course of action for GCC is to have its static checker be extensible through customizable rulesets. Third parties can provide a licensed MISRA ruleset, and GCC shops can provide house-rules stylecheckers. Everyone goes home happy.
                    I'm not exactly happy about this kind of crap. It implies environment is hard to setup - and you have to use some proprietary crap. Which is unfortunate to say the least. Maybe story with AV1 vs h.265 should repeat on this level, where opensource-friendly set of comparable rules is re-created - and checked by opensource compilers.
                    Last edited by SystemCrasher; 04-01-2020, 09:22 AM.

                    Comment

                    Working...
                    X