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

Groups > comp.arch.embedded > #27630

Re: Source code static analysis tool recommendations

Show all headers | View raw

On 08/02/18 18:58, Stefan Reuther wrote:
> Am 07.02.2018 um 20:54 schrieb David Brown:

<snip, as it's getting way off topic>

> Everyone got their dark corners.

That is a fair summary!

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

Yes, but the world has moved on since then, and the only reason MS did
not gradually supersede the messiest parts of WinAPI with better
versions from C99 (uint32_t instead of DWORD, inline instead of macros,
etc.) is that they did not make a C99 compiler.  Some design choices you
have to live with because a clean break is not possible, some you get
stuck with because a clean break is too expensive, but some we live with
because no one bothered to make the change.

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

Yes, indeed - gcc and its static error checking is excellent, but very
far from perfect.

> 
> Last two weeks' disappointments: '1 << 31' is not a warning although it
> has unspecified behaviour.

Left shift 1 << 31 (with 32-bit ints) is undefined behaviour, not
unspecified behaviour (there is a big difference) in the C standards.
However, gcc treats some additional aspects of signed << as defined
behaviour.  Unfortunately, the documentation does not give the details,
but it is reasonable to suppose that it treats this as two's complement
shifting.  Being undefined in the C standards does not preclude a
compiler from having well-defined behaviour for the expression.

(I'd have preferred a warning, personally.  And the weak documentation
here is definitely a flaw.)

> It accepts VLAs in C++ by default even with
> '-std=c++11 -ansi', and requires '-pedantic' to notice it.

That is in accordance with the gcc documentation.  "-ansi" merely
selects the standard, and should arguably give an error when used with
"-std=c++11" as "-ansi" is equivalent to "-std=c90" or "-std=c++98"
depending on the language.  It does not enable other diagnostics or
disable gcc extensions - it picks the basic standards and disables any
gcc extensions that conflict with them.  Thus it tells the compiler that
it needs to be able to compile all C90 or C++98 programs, even if you
happen to have functions called "asm" or "typeof".  It does /not/ tell
the compiler to reject programs that are not standard-conforming C90 or
C++98 programs.

"-pedantic" tells the compiler to enable all diagnostics required by the
standards.  Note that this /still/ does not mean rejecting programs
which use gcc extensions, or other code that does not have fully defined
behaviour in the standards.  It means providing diagnostics when the
standards explicitly say so, even if gcc would normally give meaning to
the code as an extension (such as using VLA's outside of C99/C11).

So no bugs there - just some misunderstandings about the gcc flags.  You
are not the first person to make such mixups, so arguably the choice of
flag names or the documentation could be better.

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

That can be true.  But I think using any tool for QA requires a careful
understanding of the tool and its options.  I would not say that gcc is
a good static analysis tool - I would say that gcc used appropriately
with a careful choice of flags and warnings is a good static analysis
tool.  And I would say that about other tools too - /no/ static analysis
tool I have looked at works as I would like it without careful choices
of flags.

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