I see Martin Liska added a bunch of bugs found by the clang static analyzer as blocking this... Martin, did you verify that cppcheck catches them, too, or are we using this bug for static analyzers in general now? It's ok if it's the latter, we'll just need to update the title...

(In reply to Eric Gallager from comment #1)
> I see Martin Liska added a bunch of bugs found by the clang static analyzer
> as blocking this... Martin, did you verify that cppcheck catches them, too,
> or are we using this bug for static analyzers in general now? It's ok if
> it's the latter, we'll just need to update the title...

Yes, I would like to extend usage of this meta bug. I've just updated the title.
About the cppcheck, I'm running that with:

$ cppcheck --enable=all --project=compile_commands.json -j16
and my impression is that it does not work for C++ files:
https://pastebin.com/ZK320Ebt
?

--language=c++ seems to be required for C++ code.

--force helps cppcheck to avoid a too-early finish.

I use the current development cppcheck code, although it's fair to say that
new features rarely work 100% perfectly first time and usually take a week
or two before they mature on real code. 

But that's development code for you ;->

(In reply to David Binderman from comment #3)
> --language=c++ seems to be required for C++ code.

That works for me, thank you!

> 
> --force helps cppcheck to avoid a too-early finish.
> 
> I use the current development cppcheck code, although it's fair to say that
> new features rarely work 100% perfectly first time and usually take a week
> or two before they mature on real code. 

Yep, I've just bumped openSUSE package to the latest release that was released few days ago.

> 
> But that's development code for you ;->

Some of the bugs that this one depends upon might be useful inspiration for the new analyzer that David Malcolm is working on.

For this C++ code:

// reading 8 bytes from a 5 byte field

# include <stdint.h>
# include <cstring>

struct S
{
	char a[ 5];
	short b;
};

void f( const S * ps)
{
	uint64_t n;

	memcpy( &n, ps->a, sizeof( uint64_t));
}

derived from recent Linux kernel, gcc has nothing to say:

$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra feb10a.cc
$ 

Interestingly, clang++ doesn't say much either:

$ clang++ -c -O2 -Wall -Wextra feb10a.cc
$ 

Adding _FORTIFY_SOURCE=2 doesn't help. Here is cppcheck in action:

$ /home/dcb/cppcheck/trunk/cppcheck  feb10a.cc
feb10a.cc:17:16: error: Buffer is accessed out of bounds: ps->a [bufferAccessOutOfBounds]
 memcpy( &n, ps->a, sizeof( uint64_t));
               ^
$

For this C++ code:

// Division by zero.

extern void g();

void f()
{
    unsigned int vsync_rate_hz = 0;
    unsigned int frame_time_microsec = 1000000 / vsync_rate_hz;

    g();
}

gcc and clang have nothing to say, even with -g -O2 -Wall -Wextra 
but cppcheck finds the problem.

updating title to include PVS studio bugs

(In reply to Eric Gallager from comment #8)
> updating title to include PVS studio bugs

actually it looks like there was already a previous meta-bug for PVS-Studio, bug 77421, but it's closed already... do we want to reopen that one, or use this one for PVS-Studio bugs as well?