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

Groups > comp.arch.embedded > #27620

Re: Source code static analysis tool recommendations

Show all headers | View raw

Am 06.02.2018 um 23:02 schrieb David Brown:
> On 06/02/18 19:05, Stefan Reuther wrote:
>> Problem is, we're actually doing C++, where MISRA imposes the same rules
>> for numbers, but would actually require us to write
>>
>>        uint32_t MASK = static_cast<uint32_t>(1) << 17;
>>
>> which is pretty much noise for my taste.
> 
> That's MISRA for you - rules for rules sake, no matter how ugly and
> incomprehensible your code ends up.  In situations like this, it totally
> misses the point.

Exactly. Now tell that the people who want cool downward pointing charts
on their PowerPoints to justify the money spent on the checker...

>> I like to use this actual definition from Windows APIs as a "how not"
>> example for cast-addicts:
>>
>>     #define MAKELONG(a, b) ((LONG) (((WORD) (((DWORD_PTR) (a)) & \
>>        0xffff)) | ((DWORD) ((WORD) (((DWORD_PTR) (b)) & 0xffff))) << 16))
> 
> I doubt if anyone will hold up the Windows API as a shining example of
> good design and clear programming!

Actually, the Windows API isn't too bad. The combination of rules that
built 16-bit Windows are borderline genius (e.g. how do you do virtual
memory on an 8086 that has not any hardware support for that?). The
Win32 API has async I/O, wait for multiple semaphores, etc., all of
which was bolted-on in Linux years later.

But having a C API (i.e. no inline functions), and evolving that through
years, will lead to monstrosities like the above. I would have written

    inline LONG makeLong(WORD a, WORD b) { return ((LONG)a << 16) | b; }

and leave the truncating to the compiler.

>>>>> In MISRA C, the literal 1 is a char not an int?
>>>>
>>>> Yes.
>>>
>>> No.  You are mixing MISRA rules with language rules.
>>>
>>> MISRA provides rules on how to write C - it most certainly does not
>>> /change/ C.  In C, the literal 1 is an decimal integer constant of type
>>> "int" (section 6.4.1.1).
>>>
>>> As a coding standard, MISRA /can/ have rules to say that you are not
>>> allowed to /use/ a literal here - but it cannot change its meaning in
>>> the language.
>>
>> MISRA defines a subset of C, and a program must follow the rules of that
>> subset. Of course that can be an own type system.
> 
> No, it cannot - it /has/ to use the C type system when you are
> programming in C.

Not as long as its own type system defines a subset. A coding standard
cannot define a '+' operator that adds two strings. But it can surely
say "although the C standard allows you to add an 8-bit unsigned and a
16-bit signed to get 32-bit signed, I won't allow that".

>> The most important takeaways I have from MISRA is: think about what you
>> do and why you do it, and: you need a deviation procedure that allows
>> you to break every rule. That deviation procedure is what makes MISRA
>> work because it rules out laziness as a reason for not doing something.
>> I won't write a deviation request to be allowed to leave out the {}'s,
>> but if my design requires me to have malloc and recursion, I want to
>> have that!
> 
> I have nothing against thinking!  But I /do/ have something against
> having to write a deviation report in order to avoid a cast monstrosity
> just because the rules say that "1" is not an int.

Exactly.

(Just today had another discussion because Klocwork spit out new
warnings. One "remove this error handling because I think this error
does not occur", one "remove this variable initialisation because I
think this is a dead store", two "this variable isn't used [but I see it
being used the next line]". This surely justifies leaving everything
behind and pet the tool.)


  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