Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #27606

Re: Source code static analysis tool recommendations

From Stefan Reuther <stefan.news@arcor.de>
Newsgroups comp.arch.embedded
Subject Re: Source code static analysis tool recommendations
Date 2018-02-04 10:18 +0100
Message-ID <p56mkp.2a0.1@stefan.msgid.phost.de> (permalink)
References <p52lfh$nrr$1@gioia.aioe.org> <teo97d1vcjb3g15npbtkci906cven11rf7@4ax.com> <p532dr$196u$1@gioia.aioe.org> <23oa7d9a3nks55apfgduiobie10ijob7bm@4ax.com> <p54og4$a65$1@reader2.panix.com>

Show all headers | View raw


Am 03.02.2018 um 17:37 schrieb Grant Edwards:
> On 2018-02-03, George Neuner <gneuner2@comcast.net> wrote:
>> I haven't seen PC-Lint in many years, so I can't comment on that.
>> Splint and cppcheck are free alternatives that are worth a look.  
> 
> I haven't tried splint it years, but it used to be completely
> useless for real code.  It would warn you about things like this:
> 
> 
>     uint8_t b;
>     b = 1;
> 
>   or 
> 
>     uint8_t i,j;
>     [...]    
>     i = j+1;

The latter gives a warning with gcc "-Wconversion" as well. Although I
was long opposing that warning, it's hard to argue your head out of it
if your company's software already had a few incidents with it. For
control code, it is definitively possible to get "-Wconversion"-free;
for computational code, it's some more work but possible (e.g. make a
'sample_add' inline function that does the casting, and use that).

What I find more annoying is that MISRA finds this

     uint32_t MASK = UINT32_C(1) << 17;

objectionable. '1', no matter how spelled, has type 'char' for MISRA,
and cannot be shifted by 17 bits.


  Stefan

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 13:32 -0800
  Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-02 18:24 -0500
    Re: Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 17:13 -0800
      Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-03 03:40 -0500
        Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-03 11:45 +0100
        Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-03 16:37 +0000
          Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-04 10:18 +0100
            Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-04 15:12 +0000
              Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-05 18:48 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-05 23:18 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-06 19:25 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 22:53 +0100
                Re: Source code static analysis tool recommendations Richard Damon <Richard@Damon-Family.org> - 2018-02-06 21:34 -0500
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:06 +0100
                Re: Source code static analysis tool recommendations Jack <jack4747@gmail.com> - 2018-02-05 23:32 -0800
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 10:23 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-06 19:05 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 23:02 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-07 02:02 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:21 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-08 00:57 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-08 10:46 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-07 20:04 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 20:54 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-08 18:58 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-09 09:17 +0100
                Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:55 +1100
                Re: Source code static analysis tool recommendations Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-02-10 19:59 -0500
                Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:49 +1100

csiph-web