Re: Source code static analysis tool recommendations

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.arch.embedded
Subject	Re: Source code static analysis tool recommendations
Date	2018-02-07 09:21 +0100
Organization	A noiseless patient Spider
Message-ID	<p5ecto$hab$1@dont-email.me> (permalink)
References	(7 earlier) <p5a8to.4v4.1@stefan.msgid.phost.de> <p5bs5l$v6a$1@dont-email.me> <p5cu9s.3s8.1@stefan.msgid.phost.de> <p5d8ld$6m3$1@dont-email.me> <fdv1ghFlrbbU1@mid.dfncis.de>

Show all headers | View raw

On 07/02/18 02:02, Hans-Bernhard Bröker wrote:
> Am 06.02.2018 um 23:02 schrieb David Brown:
>> On 06/02/18 19:05, Stefan Reuther wrote:
> 
>>> 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.  
> 
> If only.  At least in the 2004 edition, they pulled an entire
> hypothetical integer type system named "underlying type" out of thin air
> and based some of their rules on that, totally mucking up any clear
> picture of the actual C integer semantics anyone might still have had in
> their mind.
> 

And then they renamed it to "essential type" in MISRA 2012 - perhaps
because when doing MISRA C++, they discovered that C++ already uses the
term "underlying type".

And yes, I fully agree about it messing up the C code and how people
understand it.

> And yes, that utter phantasy of theirs does indeed claim the existence
> of integer constants of a type smaller than int.  Such a thing has never
> existed in the entire history of at least roughly standard-conforming C
> compilers, and it flat-out contradicts the actual semantics of C integer
> constants and conversions.  Didn't stop them, though.

But it will not affect the meaning of the code to a C compiler, which
only deals with C types.  As you say, it can affect C checkers - but not
a C compiler, at least not when running in standard modes.

> 
> What it means is that a MISRA 2004 checker will indeed pretend that the
> type of 1U is uint8_t(!), totally defeating the purpose of the UINT32C()
> macro if the compiler/libc happens to implement that by suffixing a 'U'.
> 
> So in a MISRA 2004 environment, one had better forget those macros even
> exist --- I obviously did :-).  You'll really have to write 1UL,
> (uint32_t)1 or equivalent, instead.
> 
> If there's method to that madness, it eludes me.

I have seen bugs in a certain massively popular, expensive but nameless
(to protect the guilty) 8051 compiler in the way it handled integer
promotions.  I don't remember the details (it was a colleague that used
the tool), but it is conceivable that the compiler was running in some
sort of "MISRA mode" with different semantics for types than standard C.

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