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

Groups > comp.arch.embedded > #27623

Re: Source code static analysis tool recommendations

Show all headers | View raw

On 07/02/18 20:04, Stefan Reuther wrote:
> 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.

That is not what I am talking about.  There have been plenty of useful 
(and some imaginative) features in Windows API, no doubts there.  (The 
async I/O functions needed to be in Windows because it was originally 
pretty much single-tasking and single-threaded.  Linux didn't have 
nearly as much need of it because you could quickly and cheaply create 
new processes, and because of the "select" call.  Async I/O was 
essential to Windows, and merely "nice to have" on other systems.)

The mess of Windows API is the 16 different calling conventions, the 
23.5 different non-standard types duplicating existing functionality 
(while still impressively managing to mix up "long" and pointers, 
leading to it being the only 64-bit system with 32-bit "long"), function 
calls with the same name doing significantly different things in 
different versions of the OS (compare Win32s, Win9x and WinNT APIs), and 
beauties such as the "CreateFile" call that could handle every kind of 
resource except files.

> 
> But having a C API (i.e. no inline functions), 

C has had inline functions for two decades.  The lack of inline 
functions in the Windows C world is purely a matter of laziness on MS's 
part in not providing C99 support in their tools.  It is an absurd and 
unjustifiable gap.

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

However it is written, there should be no pointer types in there!

But yes, there are entirely understandable "historical reasons" for at 
least some of the baggage in the WinAPI.  The design started out as a 
complete mess from an overgrown toy system rushed to the market without 
thought other than to cause trouble for competitors.  The Windows and 
API design has been a lot better, and lot more professional, since the 
days of NT - but it takes a long time to deal with the leftovers.  There 
has never been a possibility of clearing out the bad parts and starting 
again.

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

Yes, that's true.  But what it /cannot/ do is say that if you add an 
8-bit signed and a 16-bit signed you will get a 16-bit signed (on a 
32-bit system).  It can't change the rules of C, or the way the types 
work - all it can do is add extra restrictions.

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

I have had more luck using gcc, and its increasingly more sophisticated 
static warnings.  At least then I know the static error checking and the 
compiler agree with each other!

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