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

Groups > comp.arch.embedded > #27628

Re: Source code static analysis tool recommendations

Show all headers | View raw

Am 07.02.2018 um 20:54 schrieb David Brown:
> On 07/02/18 20:04, Stefan Reuther wrote:
>>>> 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.)

Being able to create processes does not help if you actually need
threads to be able to efficiently communicate, e.g. between a GUI thread
and a background thread. 'select' does not allow you to wait on
semaphores, meaning you have to emulate this with a self-pipe. Now that
we have 'eventfd' and native threads - bolted-on years later - it starts
to make sense somehow.

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

This sounds vastly exaggerated. I haven't tried Win32s, but so far the
only difference between Win9x and WinNT APIs was an occasional error
return in wrong format, INVALID_HANDLE instead of NULL or something like
that.

POSIX APIs give you beauties such as 'int' vs 'socklen_t', I/O functions
that take a 'size_t' size but return a 'ssize_t' result, error codes
such as EINTR, the whole mess of 'lseek'/'lseek64' and
'off_t'/'off64_t'. Everyone got their dark corners.

>> But having a C API (i.e. no inline functions), 
> 
> C has had inline functions for two decades.

Windows has existed for two-and-a-half...

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

In general, I agree, but unfortunately sometimes even gcc disappoints.

Last two weeks' disappointments: '1 << 31' is not a warning although it
has unspecified behaviour. It accepts VLAs in C++ by default even with
'-std=c++11 -ansi', and requires '-pedantic' to notice it.

This makes it harder to convince QA people that just using gcc is enough.


  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