Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27617
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Source code static analysis tool recommendations |
| Date | 2018-02-06 23:02 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <p5d8ld$6m3$1@dont-email.me> (permalink) |
| References | (5 earlier) <p56mkp.2a0.1@stefan.msgid.phost.de> <p577t1$o54$1@reader2.panix.com> <p5a8to.4v4.1@stefan.msgid.phost.de> <p5bs5l$v6a$1@dont-email.me> <p5cu9s.3s8.1@stefan.msgid.phost.de> |
On 06/02/18 19:05, Stefan Reuther wrote:
> 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.
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.
>
> 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!
>>>> 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. It can discuss other aspects of types or features in
your code, and provide extra rules - but that does not change the types
in the code.
>>> 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.
Ah, okay then. I have MISRA 1998 and MISRA 2012, but not MISRA 2004.
They seem to change a fair bit in their layout, organisation and wording.
>
> MISRA C++ has a similar rule but I don't have that document at hand.
>
So it does. I have MISRA C++ 2008.
>> 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.
And then again in 2012...
>
>> 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!
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.
>
> 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.
>
Fair 'nuf.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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