[CCd wine-devel]
Awesome, thanks Matthew. Full credit to James Hawkins who figured out what was tripped up the scanner anyway, I just forwarded the info on.
So there we go guys! We are down 220 bugs overnight :)
Matthew Hayward wrote:
Hello Mike, Thanks for pointing out the WideCharToMultiByte function. I have provided back end configuration indicating it is not an error to send in parameter #4 as negative, and that eliminated around 220 reports. We try to have a low false positive rate, but sometimes when we misunderstand an interface like that we will see a bug report at each invocation of the interface, fortunately most of the time, as in this case, we can configure around it easily. Thanks again for pointing this out to us!
"Mike Hearn" mike@plan99.net wrote:
Awesome, thanks Matthew. Full credit to James Hawkins who figured out what was tripped up the scanner anyway, I just forwarded the info on.
So there we go guys! We are down 220 bugs overnight :)
Matthew Hayward wrote:
Hello Mike, Thanks for pointing out the WideCharToMultiByte function. I have provided back end configuration indicating it is not an error to send in parameter #4 as negative, and that eliminated around 220 reports. We try to have a low false positive rate, but sometimes when we misunderstand an interface like that we will see a bug report at each invocation of the interface, fortunately most of the time, as in this case, we can configure around it easily. Thanks again for pointing this out to us!
The same kind of error is reported for mlang.dll, but the situation is worse there since the length parameter is unsigned but still accepts -1 as a magic length indicator.
Dmitry Timoshkov wrote:
The same kind of error is reported for mlang.dll, but the situation is worse there since the length parameter is unsigned but still accepts -1 as a magic length indicator.
Can you give me the file this function is defined in, and an example FP? Then I can see about configuring it away.
"Matthew Hayward" mhayward@coverity.com wrote:
The same kind of error is reported for mlang.dll, but the situation is worse there since the length parameter is unsigned but still accepts -1 as a magic length indicator.
Can you give me the file this function is defined in, and an example FP? Then I can see about configuring it away.
The APIs are defined in dlls/mlang/mlang.c and used by the test application in wine/dlls/mlang/tests/mlang.c. Looking at the today's Coverity reports it appears that Coverity no more reports that kind of a defect. I'm not sure if that's a result of a WideCharToMultiByte fix.
Looking at the wine/dlls/mlang/tests/mlang.c reports I see another possible misunderstanding: IMultiLanguage2_ConvertStringFromUnicode takes a length of the target buffer in the last parameter and returns a resulting string length in the same variable. The scanner appears to not undrestand it.
149 ok(lenW == 0, "expected lenW 0, got %u\n", lenW); 150 151 memset(bufA, 'x', sizeof(bufA)); 152 lenW = -1;
Event assignment: Assigning "256" to "lenA" Also see events: [overrun-local]
153 lenA = sizeof(bufA); 154 TRACE_2("Call IMultiLanguage2_ConvertStringFromUnicode\n"); 155 ret = IMultiLanguage2_ConvertStringFromUnicode(iML2, NULL, 1252, stringW, &lenW, bufA, &lenA);
At conditional (15): "(winetest_set_location), (0 != 0)" taking false path At conditional (16): "ret == 0" taking true path
156 ok(ret == S_OK, "IMultiLanguage2_ConvertStringFromUnicode failed: %08lx\n", ret);
At conditional (17): "(winetest_set_location), (0 != 0)" taking false path At conditional (18): "lenA == lstrlenA" taking true path
157 ok(lenA == lstrlenA(stringA), "expected lenA %u, got %u\n", lstrlenA(stringA), lenA);
At conditional (19): "(winetest_set_location), (0 != 0)" taking false path At conditional (20): "lenW == lstrlenW" taking true path
158 ok(lenW == lstrlenW(stringW), "expected lenW %u, got %u\n", lstrlenW(stringW), lenW);
Event overrun-local: Overrun of static array "bufA" of size 256 at position 256 with index variable "lenA" Also see events: [assignment] At conditional (21): "(winetest_set_location), (0 != 0)" taking false path
159 ok(bufA[lenA] != 0, "buf should not be 0 terminated\n"); 160 bufA[lenA] = 0; /* -1 doesn't include 0 terminator */ 161 ok(!lstrcmpA(bufA, stringA), "bufA/stringA mismatch\n");
-
Dmitry Timoshkov -
Matthew Hayward -
Mike Hearn