LibRaw, Coverity SCAN, PVS-Studio

I read a note about checking a small LibRaw project using Coverity SCAN. From the article it follows that nothing interesting was found. I decided to try, can I find something with the PVS-Studio analyzer.

Libraw

LibRaw is a library for reading RAW files received from digital cameras (CRW / CR2, NEF, RAF, DNG and others). Website: http://www.libraw.org/

Check with Coverity SCAN

But the article that prompted me to check the project with PVS-Studio: " About static analysis C ++ ". Briefly quote the main part of the article:

Coverity SCAN: 107 warnings, of which about one third are from High Impact.
')
From High Impact:

Pieces 10 in Microsoft STL

Some more of this approximately the form:

int variable; if(layout==Layout1) variable=value1; if(layout==Layout2) variable=value2; 

And this is given a warning, they say inaccurately, not initialized variable. I agree with him on the general feelings, so do not do it. But in real life there are two kinds of layout - and this is clearly spelled out in the calling code. Those. the machine has enough data to figure out that this is not a 'high impact', but just a little awkward.

A number of warnings, saying unsigned short when expanding to 32-64 bits, can be painful to bite. I don’t want to argue with that - formally the machine is right, but in fact in these unsigned short live image sizes and up to 32767 they will not grow in the coming years.

Those. again, no fixing is necessary - in the case of a given subject area.

All other problems found by 'High Impact' are just false positives. Those. the code, I agree, is not perfect (you should have seen this code from dcraw!), but everything found is not an error.

Check with PVS-Studio

Now let's see if we can find something after the Coverity to the PVS-Studio analyzer. Of course, there are no expectations about the discovery of super-errors, but it's still interesting to try.

The PVS-Studio analyzer issued 46 general-purpose warnings (first and second level of importance).

I suggest looking at code snippets that I found interesting.

Typos

 void DHT::hide_hots() { .... for (int k = -2; k < 3; k += 2) for (int m = -2; m < 3; m += 2) if (m == 0 && m == 0) continue; else avg += nraw[nr_offset(y + k, x + m)][kc]; .... } 

PVS-Studio warning: V501 operator: m == 0 && m == 0 dht_demosaic.cpp 260

Apparently we are dealing with a typo. Most likely, the check should have been like this:

 if (k == 0 && m == 0) 

An identical fragment is also available in the aahd_demosaic.cpp file (line 199).

Priority of operations

 int main(int argc, char *argv[]) { int ret; .... if( (ret = RawProcessor.open_buffer(iobuffer,st.st_size) != LIBRAW_SUCCESS)) { fprintf(stderr,"Cannot open_buffer %s: %s\n", argv[arg],libraw_strerror(ret)); free(iobuffer); continue; } .... } 

PVS-Studio warning: V593 Consider reviewing the expression A = B! = C 'kind. The expression is calculated as the following: 'A = (B! = C)'. dcraw_emu.cpp 468

The error associated with the priorities of operations. At the beginning, the comparison is “RawProcessor.open_buffer (iobuffer, st.st_size)! = LIBRAW_SUCCESS”. Then the result of this comparison is written to the variable 'ret'. If an error occurs, the wrong error code will be printed to the file. Not a critical shortcoming, but still worth telling about it.

Shift negative numbers

 unsigned CLASS pana_bits (int nbits) { .... return (buf[byte] | buf[byte+1] << 8) >> (vbits & 7) & ~(-1 << nbits); .... } 

PVS-Studio warning: V610 Undefined behavior. Check the shift operator '<<. The left operand '-1' is negative. dcraw_common.cpp 1827

Shifting negative values ​​results in an undefined behavior. Such tricks are often used, and the program pretends what works. But in fact, you can not rely on such code. More information about the shifts of negative numbers can be read here: Without knowing the ford, do not climb into the water. Part Three

Similar shifts can be found here:

• dcraw_common.cpp 1851
• dcraw_common.cpp 2085
• dcraw_common.cpp 2814
• dcraw_common.cpp 6644

Strange Fragments

 void DHT::illustrate_dline(int i) { .... int l = ndir[nr_offset(y, x)] & 8; l >>= 3; l = 1; .... } 

PVS-Studio warning: V519 The 'l' variable is assigned values ​​twice successively. Perhaps this is a mistake. Check lines: 671, 672. dht_demosaic.cpp 672

Perhaps this is not a mistake and "l = 1" is written on purpose. However, the code looks suspicious.

Here is another suspicious place:

 void CLASS identify() { .... if (!load_raw && (maximum = 0xfff)) .... } 

PVS-Studio warning: V560 A part of conditional expression is always true: ((imgdata.color.maximum) = 0xfff). dcraw_common.cpp 8496

Conclusion

Both analyzers found very little. This is natural for small projects. However, it was still interesting to conduct an experiment to verify LibRaw.