Coverity: Update to version 7.6.0

[David Stacey]

If there are no objections, I'd like to update our weekly Coverity scan
to use Coverity Analysis 7.6.0 (presently we're using 7.5.0). There
should be fewer false positives this week, but there might be some new
coding defects picked up also.

Dave.

[Corinna Vinschen]

If there are no objections, I'd like to update our weekly Coverity scan to
use Coverity Analysis 7.6.0 (presently we're using 7.5.0). There should be
fewer false positives this week, but there might be some new coding defects
picked up also.

No worries here. Just go ahead.


Thanks,
Corinna

[David Stacey]

Post by Corinna Vinschen

If there are no objections, I'd like to update our weekly Coverity scan to
use Coverity Analysis 7.6.0 (presently we're using 7.5.0). There should be
fewer false positives this week, but there might be some new coding defects
picked up also.

No worries here. Just go ahead.

Thanks. I'm running the analysis now using the same source code as last
week. So any differences we see in the analysis results will be down to
changes between Coverity Analysis 7.5.0 and 7.6.0. Results should be
available on the Coverity Scan website in a couple of hours.

I'll take a look at any new warnings tomorrow evening. If you have time
to take a look during the day then please let me know the numeric ID of
any issues you fix (or mark them as 'fix submitted') so we don't
duplicate effort.

Cheers,

Dave.

[Corinna Vinschen]

Post by David Stacey

Post by Corinna Vinschen

If there are no objections, I'd like to update our weekly Coverity scan to
use Coverity Analysis 7.6.0 (presently we're using 7.5.0). There should be
fewer false positives this week, but there might be some new coding defects
picked up also.

No worries here. Just go ahead.

Thanks. I'm running the analysis now using the same source code as last
week. So any differences we see in the analysis results will be down to
changes between Coverity Analysis 7.5.0 and 7.6.0. Results should be
available on the Coverity Scan website in a couple of hours.
I'll take a look at any new warnings tomorrow evening. If you have time to
take a look during the day then please let me know the numeric ID of any
issues you fix (or mark them as 'fix submitted') so we don't duplicate
effort.

Thanks. I had a quick look and CID 109854 is certainly a false positive
because it counts wrongly in the wide character case:

CHAR fmtbuf[10], *fmt = fmtbuf;

It knows wchar_t is 2 bytes at this point. Three time ++ means, 14
bytes left.

STRCPY (fmt, CQ(".*u"));

At this point, Coverity looks at the expression L".*u" and counts 4 bytes
per wide char in the string expression, which isn't true for us. The
string takes 8 bytes only.


Corinna

[David Stacey]

Post by Corinna Vinschen

Post by David Stacey

Post by Corinna Vinschen

If there are no objections, I'd like to update our weekly Coverity scan to
use Coverity Analysis 7.6.0 (presently we're using 7.5.0). There should be
fewer false positives this week, but there might be some new coding defects
picked up also.

No worries here. Just go ahead.

Thanks. I'm running the analysis now using the same source code as last
week. So any differences we see in the analysis results will be down to
changes between Coverity Analysis 7.5.0 and 7.6.0. Results should be
available on the Coverity Scan website in a couple of hours.
I'll take a look at any new warnings tomorrow evening. If you have time to
take a look during the day then please let me know the numeric ID of any
issues you fix (or mark them as 'fix submitted') so we don't duplicate
effort.

Thanks. I had a quick look and CID 109854 is certainly a false positive
CHAR fmtbuf[10], *fmt = fmtbuf;
It knows wchar_t is 2 bytes at this point. Three time ++ means, 14
bytes left.
STRCPY (fmt, CQ(".*u"));
At this point, Coverity looks at the expression L".*u" and counts 4 bytes
per wide char in the string expression, which isn't true for us. The
string takes 8 bytes only.

Sorry for the delay in replying. Yes, your analysis of CID 109854 is
quite correct. The wide string literal is an array of const wchar_t [1].
Coverity should know that this is 2 bytes per character, but seems to
count 4 when it sees the 'L' encoding prefix. I've marked this as a
false positive in Coverity.

The other two new warnings look genuine enough, although both are in
newlib. I've taken the liberty of reporting CID 109855 to the newlib
list [2] - let's hope they're friendly to newbies. If this is accepted
then I'll send a patch for CID 109856 as well.

Dave.

[1] - http://www.lcdf.org/c%2B%2B/clause2.html - section 2.13.4,
paragraph 1.
[2] - https://sourceware.org/ml/newlib/2015/msg00417.html