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

Groups > comp.arch.embedded > #27614

Re: Source code static analysis tool recommendations

Show all headers | View raw

Am 06.02.2018 um 10:23 schrieb David Brown:
> On 05/02/18 18:48, Stefan Reuther wrote:
>> Am 04.02.2018 um 16:12 schrieb Grant Edwards:
>>> On 2018-02-04, Stefan Reuther <stefan.news@arcor.de> wrote:
>>>> 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.
>>>
> 
> The literal "1" cannot be shifted by 17 bits if an int has less than 18
> bits.  But it never has type "char".
> 
> As far as I can tell, it is perfectly acceptable in MISRA to write:
> 
> 	uint32_t MASK = ((uint32_t) 1) << 17;

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.

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))

>>> 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.

>> MISRA C 6.10.4 "Underlying type".
> 
> I can't find any such section in MISRA 1998 or MIRCA 2012, nor any
> concept of "underlying type".  Could you be more specific in your
> reference?  Or use the correct MISRA term?

MISRA-C:2004, chapter 6.10.4 "Underlying type". A few paragraphs in, it
defines "The underlying type of an integer constant expression is
therefore defined as follows: 1. if the actual type of the expression is
(signed) int, the underlying type is defined to be the smallest integer
type which is capable of representing its value", followed by a table
where '1' falls into the category '8 bit signed' which would be (signed)
char.

MISRA C++ has a similar rule but I don't have that document at hand.

> From Appendix D, detailing "essential types", a signed integer constant
> has "essential type" of the smallest signed integer type that can
> express it - for 1, this will be "signed char" (but /not/ "char").

That sounds like you have a completely different document in front of
you than me - which wouldn't be too surprising given that the document
changed completely between 1998 and 2004.

> I am glad I don't have to program to MISRA.  It has plenty of good
> rules, but most of those are either blindingly obvious or covered by
> "don't use undefined behaviour, and be careful about implementation
> defined behaviour".  And it has a wide range of junk and actively /bad/
> rules that should be replaced by "get a decent compiler and enable
> warnings, or use a linter if your compiler is crap" and "learn to
> program in C".

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!

That's why my advice to OP avoid the "fix all findings" approach. That's
the easy way for management get some cool downward-pointing charts on
PowerPoint, but also the easy way to completely ruin a moderatly ok
software.


  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