Автор: Александр Чибисов
Проект ReactOS продолжает активно развиваться, и размеры кода неуклонно растут. 16 февраля 2016 вышла новая версия операционной системы. Это хороший повод в очередной раз подвергнуть её статическому анализу. Для проверки используется анализатор PVS-Studio версии 6.02.
Введение
Решил попробовать себя в деле написания статей, связанных со статическим анализом. Для анализа и написания статьи был выбран проект ReactOS.
ReactOS - это современная открытая операционная система, основанная на принципах работы Windows NT и Wine. Главной целью проекта является создание системы, полностью совместимой с приложениями и драйверами устройств, написанных для windows.
Проект уже проверялся ранее. Про результаты проверок можно прочитать в статьях:
- PVS-Studio: анализируем код операционной системы ReactOS
- Большой отчет о повторной проверке проекта ReactOS
Со времени последней проверки количество проектов внутри решения увеличилось до 963.
По итогам проверки было обнаружено 4027 предупреждений общего назначения в 5396 файлах проекта. Разработчики не прошли мимо результатов прошлой проверки, о чём свидетельствует уменьшившееся количество ошибок. Но проект развивается и неизбежно рождает новые ошибки. Именно поэтому необходимо регулярно проводить анализа кода.
Очевидно, внимательно изучить все предупреждения не представляется возможным. Поэтому в статье будут отражены только наиболее интересные и подозрительные места. Наверняка остались ошибки, пропущенные мной. Не говоря уже о предупреждениях, найденных диагностиками, связанными с 64-битными ошибками и микро-оптимизациями.
Демонстрационной версии PVS-Studio недостаточно для проверки такого крупного проекта, но компания ООО "СиПроВер" предоставила мне лицензию для проверок проектов с открытым исходным кодом.
Опечатки
Анализатор PVS-Studio хорошо выявляет различные опечатки, легко теряющиеся среди больших объемов кода. Посмотрим, что нашлось на этот раз.
Повторное присвоение
| C++ | 1
2
3
4
5
6
7
| Int xmlNanoFTPList(....)
{
....
closesocket(ctxt->dataFd); ctxt->dataFd = INVALID_SOCKET; //<-
ctxt->dataFd = INVALID_SOCKET; //<-
....
} |
|
В примере явно видна ошибка, где на двух соседних строчках происходит присвоение переменной одного и тоже значения. Такие ошибки происходят по причине несоблюдения правил форматирования кода. Заметить такую ошибку при обычной проверке кода достаточно сложно. Операторы расположены на одной строке и легко сливаются в единый фрагмент.
Ничего плохого в этой ошибке конечно нет, просто лишнее дублированное присваивание. Тем не менее, это всё-таки ошибка, и я решил, что о ней стоит упомянуть.
По причине дублирования кода данная ошибка встречается ещё в нескольких местах проекта:
- V519 The 'ctxt->dataFd' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1804, 1805. nanoftp.c 1805
- V519 The 'ctxt->dataFd' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1935, 1936. nanoftp.c 1936
Неверный оператор
| C++ | 1
2
3
4
5
6
7
8
| static INT CommandDumpSector(....)
{
....
SectorCount.QuadPart = DiskGeometry.Cylinders.QuadPart *
DiskGeometry.TracksPerCylinder, //<-
DiskGeometry.SectorsPerTrack;
....
} |
|
При расчёте значения переменой вместо перемножения всех нужных значений используется оператор запятая. В результате переменная получает значение DiskGeometry.SectorsPerTrack, а первое умножение двух операндов просто игнорируются. Такие ошибки часто происходят, когда переменная часто используется в нескольких соседних строках и вместо повторного ввода переменную просто скопировали из проверки выше вместе с запятой.
Лишнее присвоение
| C++ | 1
2
3
4
5
6
7
8
9
10
11
| LRESULT CDeviceManager::OnNotify(_In_ LPARAM lParam)
{
....
UINT_PTR idButton = lpttt->hdr.idFrom;
switch (idButton)
{
....
}
idButton = idButton; //<-
....
} |
|
Переменная присваивается сама себе. Фактически, это одна из последних строк в функции и все нужные операции с idButton уже проведены. В данном случае это говорит о необходимости присвоить значение какой-то другой глобальной переменой для продолжения расчетов в другой функции, или же это просто свидетельствует об обычной невнимательности, которая привела к появлению лишней операции.
Ошибки с условиями
Разнообразные ошибки в условиях приводят к неверной обработке данных и бесконечным циклам. В некоторых случаях ошибки в условиях приводят к постоянной обработке фрагментов кода, который не должен исполняться совсем или выполнен только в определенной ситуации.
Повтор операнда в условии
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| #define GCS_HELPTEXTA 0x00000001
#define GCS_VALIDATEA 0x00000002
#define GCS_HELPTEXTW 0x00000005
#define GCS_VALIDATEW 0x00000006
HRESULT WINAPI CDefaultContextMenu::GetCommandString(....)
{
if (uFlags == GCS_HELPTEXTA || uFlags == GCS_HELPTEXTW)
{
....
}
....
if (uFlags == GCS_VALIDATEA || uFlags == GCS_VALIDATEA) //<-
return S_OK;
....
} |
|
Функция работает с обычными строками и строками Unicode, поэтому все проверки проводятся дважды. В результате опечатки в условии дважды проверяется только обычная строка. Для исправления ошибки необходимо заменить вторую часть условия.
Исправленный код будет выглядеть так:
| C++ | 1
2
| if (uFlags == GCS_VALIDATEA || uFlags == GCS_VALIDATEW)
return S_OK; |
|
Неиспользуемое условие
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| SOCKET WSPAPI
WSPAccept(....)
{
....
if (CallBack == CF_REJECT)
{
*lpErrno = WSAECONNREFUSED;
return INVALID_SOCKET;
}
else
{
*lpErrno = WSAECONNREFUSED;
return INVALID_SOCKET;
}
....
} |
|
А это другой вид ошибки в условиях. В приведенном фрагменте видно, что независимо от того будет условие истинно или ложно всегда будет выполнен один и тот же блок операторов. В данном случае я не знаю особенностей кода и могу только предполагать, как его можно исправить. Возможно, необходимо доработать код внутри блоков, или же просто убрать условие, чтобы код выполнялся всегда без лишних проверок.
Подобные участки кода были замечены и в других модулях:
- V523 The 'then' statement is equivalent to the 'else' statement. crecyclebin.cpp 1357
- V523 The 'then' statement is equivalent to the 'else' statement. mapdesc.cc 733
- V523 The 'then' statement is equivalent to the 'else' statement. pattern.c 2058
- V523 The 'then' statement is equivalent to the 'else' statement. console.c 143
Логическая ошибка
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| HDEVINFO WINAPI SetupDiGetClassDevsExW(....)
{
....
if (flags & DIGCF_ALLCLASSES)
{
....
}
else if (!IsEqualIID(&list->ClassGuid, &GUID_NULL))//<-
{
if (IsEqualIID(&list->ClassGuid, &GUID_NULL)) //<-
pClassGuid = &list->ClassGuid;
....
}
....
} |
|
Диагностика V637 свидетельствует о наличии непродуманного условия в коде. В случае выполнения первого условия, второе никогда не будет выполнено, и блок кода не получит управление в любом случае. Это является примером избыточного кода.
Похожий пример выявила другая диагностика:
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
| static int xmlStreamCompile(xmlPatternPtr comp) {
....
case XML_OP_ELEM:
....
if ((comp->nbStep == i + 1) && //<-
(flags & XML_STREAM_STEP_DESC))
{
if (comp->nbStep == i + 1) { //<-
stream->flags |= XML_STREAM_FINAL_IS_ANY_NODE;
}
}
....
} |
|
В примере видно, что вторая проверка всегда будет выдавать истинный результат, и она является лишней, так как фрагмент кода получит управление независимо от этой проверки.
Чрезмерное выражение
| C++ | 1
2
3
4
5
6
7
8
9
10
11
| PVOID NTAPI RtlLookupElementGenericTableFull(....)
{
....
/* Check if we found anything */
if ((*SearchResult == TableEmptyTree) ||
(*SearchResult != TableFoundNode))
{
return NULL;
}
....
} |
|
Здесь показан фрагмент кода, где одно из выражений проверки является лишним. В случае если первое выражение будет истинным, то второе проверяться не будет. Но если проверить второе условие в данном случае, то и оно также выдаст истинный результат. Следовательно, для данного фрагмента вполне достаточно проверять только второе выражение и код следует упростить так:
| C++ | 1
2
3
4
| if (*SearchResult != TableFoundNode)
{
return NULL;
} |
|
Результат работы функции не используется
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
| #define IOleInPlaceSite_GetWindow(This,phwnd)\
( (This)->lpVtbl -> GetWindow(This,phwnd) )
static void create_shell_embedding_hwnd(WebBrowser *This)
{
HWND parent = NULL;
....
if(SUCCEEDED(hres)) {
IOleInPlaceSite_GetWindow(inplace, &parent); //<-
IOleInPlaceSite_Release(inplace);
}
....
} |
|
Функция ищет определенное окно относительно окна inplace, однако независимо от того, будет найдено окно или нет, работа функции становится бесполезной операцией, так как её результат нигде не используется.
Та же ошибка повторяется в другом месте:
V530 The return value of function 'GetWindow' is required to be utilized. oleobject.c 185
Подозрительный цикл
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| FF_T_SINT32 FF_BlockRead(....) {
FF_T_SINT32 slRetVal = 0;
....
if(pIoman->pBlkDevice->fnpReadBlocks)
{
....
slRetVal = pIoman->pBlkDevice->fnpReadBlocks(pBuffer,
ulSectorLBA, ulNumSectors, pIoman->pBlkDevice->pParam);
....
if(FF_GETERROR(slRetVal) == FF_ERR_DRIVER_BUSY) {
FF_Sleep(FF_DRIVER_BUSY_SLEEP);
}
} while(FF_GETERROR(slRetVal) == FF_ERR_DRIVER_BUSY); //<-
return slRetVal;
} |
|
- V712 Be advised that compiler may delete this cycle or make it infinity. Use volatile variable(s) or synchronization primitives to avoid this. ff_ioman.c 539
- V715 The 'while' operator has empty body. Suspicious pattern detected: 'if (expr) {...} while (expr);'. ff_ioman.c 539
- V547 Expression '(slRetVal & 0x0000FFFF) == - 10' is always false. ff_ioman.c 539
После условия расположен бестелесный цикл, выражение которого всегда будет ложным, следовательно, цикл не выполнится ни разу. Неизвестно, что именно должен делать подобный код. Но могу предположить, что здесь должна быть использована связка do .... while и оператор do просто пропустили.
Этот же код встречается ещё в одном месте проекта:
- V712 Be advised that compiler may delete this cycle or make it infinity. Use volatile variable(s) or synchronization primitives to avoid this. ff_ioman.c 564
- V715 The 'while' operator has empty body. Suspicious pattern detected: 'if (expr) {...} while (expr);'. ff_ioman.c 564
- V547 Expression '(slRetVal & 0x0000FFFF) == - 10' is always false. ff_ioman.c 564
Некорректный аргумент функции
| C++ | 1
2
3
4
5
6
7
8
| void UpdateStatusBar(void)
{
TCHAR szStatusText[128];
....
ZeroMemory(szStatusText,
sizeof(szStatusText) / sizeof(TCHAR)); //<-
....
} |
|
Функция ZeroMemory заполняет память, выделенную под массив, нулями. В данном случае, вместо размера блока для заполнения, функция получает фактическое количество элементов и из-за этого обнуляет только часть необходимого блока памяти. Для исправления ошибки этот код надо изменить так:
| C++ | 1
2
| ZeroMemory(szStatusText,
sizeof(szStatusText)); |
|
Разыменовывание потенциально нулевого указателя
В решении достаточно много фрагментов, где указатель сначала используется, а только потом значение проверяется на равенство нулю. Такой код стабильно работает, пока указатель не окажется равен нулю.
| C++ | 1
2
3
4
5
6
7
8
9
10
| NET_API_STATUS WINAPI NetUserEnum(....)
{
done:
if (ApiStatus == NERR_Success &&
EnumContext->Index < EnumContext->Count) //<-
ApiStatus = ERROR_MORE_DATA;
if (EnumContext != NULL) //<-
*totalentries = EnumContext->Count;
} |
|
Множество ошибок этого типа было исправлено со времени последней проверки. Но с того времени появилось много новых, что несомненно указывает на необходимость регулярного выполнения статического анализа кода.
| C++ | 1
| Привожу список найденных диагностических сообщений: |
|
- V595 The 'EnumContext' pointer was utilized before it was verified against nullptr. Check lines: 1166, 1169. local_group.c 1166
- V595 The 'GuiData' pointer was utilized before it was verified against nullptr. Check lines: 1458, 1465. conwnd.c 1458
- V595 The 'PartitionList->CurrentPartition' pointer was utilized before it was verified against nullptr. Check lines: 1653, 1656. usetup.c 1653
- V595 The 'PolicyAccountDomainInfo' pointer was utilized before it was verified against nullptr. Check lines: 255, 258. sidcache.c 255
- V595 The 'PropertySheetHeader' pointer was utilized before it was verified against nullptr. Check lines: 1176, 1180. devclass.c 1176
- V595 The 'This->pITextStoreACP' pointer was utilized before it was verified against nullptr. Check lines: 127, 131. context.c 127
- V595 The 'addr' pointer was utilized before it was verified against nullptr. Check lines: 2110, 2113. builtin.c 2110
- V595 The 'argv' pointer was utilized before it was verified against nullptr. Check lines: 354, 358. rundll32.c 354
- V595 The 'context' pointer was utilized before it was verified against nullptr. Check lines: 93, 98. texture.c 93
- V595 The 'driverInfo' pointer was utilized before it was verified against nullptr. Check lines: 211, 227. driver.c 211
- V595 The 'ds' pointer was utilized before it was verified against nullptr. Check lines: 257, 262. main.cpp 257
- V595 The 'ds' pointer was utilized before it was verified against nullptr. Check lines: 303, 308. main.cpp 303
- V595 The 'entry' pointer was utilized before it was verified against nullptr. Check lines: 431, 440. cmenufocusmanager.cpp 431
- V595 The 'entry' pointer was utilized before it was verified against nullptr. Check lines: 572, 575. cursoricon.c 572
- V595 The 'lpszTemp' pointer was utilized before it was verified against nullptr. Check lines: 1167, 1170. taskmgr.c 1167
- V595 The 'm_shellPidl' pointer was utilized before it was verified against nullptr. Check lines: 748, 749. ntobjfolder.cpp 748
- V595 The 'm_shellPidl' pointer was utilized before it was verified against nullptr. Check lines: 803, 804. regfolder.cpp 803
- V595 The 'new_env' pointer was utilized before it was verified against nullptr. Check lines: 432, 450. env.c 432
- V595 The 'pFM2' pointer was utilized before it was verified against nullptr. Check lines: 617, 627. regsvr.c 617
- V595 The 'pPatterns' pointer was utilized before it was verified against nullptr. Check lines: 497, 518. info.c 497
- V595 The 'pServiceStatus' pointer was utilized before it was verified against nullptr. Check lines: 194, 200. query.c 194
- V595 The 'pTLib' pointer was utilized before it was verified against nullptr. Check lines: 7863, 7865. typelib.c 7863
- V595 The 'patterns' pointer was utilized before it was verified against nullptr. Check lines: 1747, 1768. info.c 1747
- V595 The 'pcFetched' pointer was utilized before it was verified against nullptr. Check lines: 211, 216. mediatype.c 211
- V595 The 'pcchOut' pointer was utilized before it was verified against nullptr. Check lines: 2248, 2250. url.c 2248
- V595 The 'pidlChild' pointer was utilized before it was verified against nullptr. Check lines: 162, 183. shlfolder.cpp 162
- V595 The 'plpOptions[curStream]' pointer was utilized before it was verified against nullptr. Check lines: 1603, 1604. api.c 1603
- V595 The 'ppszNames' pointer was utilized before it was verified against nullptr. Check lines: 238, 245. find.c 238
- V595 The 'ppszNames' pointer was utilized before it was verified against nullptr. Check lines: 464, 485. find.c 464
- V595 The 'prbel' pointer was utilized before it was verified against nullptr. Check lines: 226, 244. recyclebin.c 226
- V595 The 'psp' pointer was utilized before it was verified against nullptr. Check lines: 2718, 2727. propsheet.c 2718
- V595 The 'pszList' pointer was utilized before it was verified against nullptr. Check lines: 613, 630. dialogs.cpp 613
- V595 The 'subtypeinfo' pointer was utilized before it was verified against nullptr. Check lines: 5559, 5564. typelib.c 5559
- V595 The 'typeInfo' pointer was utilized before it was verified against nullptr. Check lines: 943, 945. typelib.c 943
- V595 The 'user_dirids' pointer was utilized before it was verified against nullptr. Check lines: 192, 203. dirid.c 192
- V595 The 'wki' pointer was utilized before it was verified against nullptr. Check lines: 129, 133. netid.c 129
- V595 The 'wki' pointer was utilized before it was verified against nullptr. Check lines: 163, 167. netid.c 163
- V595 The 'wki' pointer was utilized before it was verified against nullptr. Check lines: 299, 302. netid.c 299
- V595 The 'Globals.win_list' pointer was utilized before it was verified against nullptr. Check lines: 542, 564. winhelp.c 542
- V595 The 'NewSubsystem' pointer was utilized before it was verified against nullptr. Check lines: 501, 503. smsubsys.c 501
- V595 The 'This->doc_host' pointer was utilized before it was verified against nullptr. Check lines: 834, 847. shellbrowser.c 834
- V595 The 'atom->ranges' pointer was utilized before it was verified against nullptr. Check lines: 817, 818. xmlregexp.c 817
- V595 The 'attr' pointer was utilized before it was verified against nullptr. Check lines: 2860, 2864. xmlschemas.c 2860
- V595 The 'atts' pointer was utilized before it was verified against nullptr. Check lines: 8640, 8649. parser.c 8640
- V595 The 'compiland' pointer was utilized before it was verified against nullptr. Check lines: 294, 301. symbol.c 294
- V595 The 'compiland' pointer was utilized before it was verified against nullptr. Check lines: 494, 499. symbol.c 494
- V595 The 'compress_formats[i].guid' pointer was utilized before it was verified against nullptr. Check lines: 946, 950. jpegformat.c 946
- V595 The 'converter' pointer was utilized before it was verified against nullptr. Check lines: 2319, 2324. info.c 2319
- V595 The 'ctx->myDoc' pointer was utilized before it was verified against nullptr. Check lines: 13108, 13111. parser.c 13108
- V595 The 'ctxt' pointer was utilized before it was verified against nullptr. Check lines: 1130, 1131. xinclude.c 1130
- V595 The 'ctxt->incTab[nr]' pointer was utilized before it was verified against nullptr. Check lines: 1420, 1429. xinclude.c 1420
- V595 The 'ctxt->input' pointer was utilized before it was verified against nullptr. Check lines: 11364, 11367. parser.c 11364
- V595 The 'ctxt->input' pointer was utilized before it was verified against nullptr. Check lines: 6734, 6738. htmlparser.c 6734
- V595 The 'ctxt->input' pointer was utilized before it was verified against nullptr. Check lines: 6802, 6810. parser.c 6802
- V595 The 'ctxt->input' pointer was utilized before it was verified against nullptr. Check lines: 6864, 6872. parser.c 6864
- V595 The 'ctxt->myDoc' pointer was utilized before it was verified against nullptr. Check lines: 13667, 13683. parser.c 13667
- V595 The 'ctxt->myDoc' pointer was utilized before it was verified against nullptr. Check lines: 819, 831. sax2.c 819
- V595 The 'ctxt->nsTab' pointer was utilized before it was verified against nullptr. Check lines: 1590, 1597. parser.c 1590
- V595 The 'current_line' pointer was utilized before it was verified against nullptr. Check lines: 558, 563. edit.c 558
- V595 The 'depth_stencil' pointer was utilized before it was verified against nullptr. Check lines: 348, 351. device.c 348
- V595 The 'device->hwbuf' pointer was utilized before it was verified against nullptr. Check lines: 909, 919. mixer.c 909
- V595 The 'es' pointer was utilized before it was verified against nullptr. Check lines: 5284, 5300. edit.c 5284
- V595 The 'formats[i].guid' pointer was utilized before it was verified against nullptr. Check lines: 1416, 1420. pngformat.c 1416
- V595 The 'formats[i].guid' pointer was utilized before it was verified against nullptr. Check lines: 1562, 1566. tiffformat.c 1562
- V595 The 'formats[i].guid' pointer was utilized before it was verified against nullptr. Check lines: 166, 170. bmpencode.c 166
- V595 The 'func' pointer was utilized before it was verified against nullptr. Check lines: 373, 376. symbol.c 373
- V595 The 'lpFindInfo' pointer was utilized before it was verified against nullptr. Check lines: 6310, 6314. listview.c 6310
- V595 The 'lpItem' pointer was utilized before it was verified against nullptr. Check lines: 4223, 4248. listview.c 4223
- V595 The 'lpNumberOfBytesRead' pointer was utilized before it was verified against nullptr. Check lines: 150, 180. rw.c 150
- V595 The 'lpiID' pointer was utilized before it was verified against nullptr. Check lines: 343, 364. exticon.c 343
- V595 The 'lpszCommandLine' pointer was utilized before it was verified against nullptr. Check lines: 283, 288. crtexe.c 283
- V595 The 'lpwh' pointer was utilized before it was verified against nullptr. Check lines: 1374, 1388. ftp.c 1374
- V595 The 'lpwszComponent' pointer was utilized before it was verified against nullptr. Check lines: 1465, 1468. internet.c 1465
- V595 The 'lpwszConnectionName' pointer was utilized before it was verified against nullptr. Check lines: 1256, 1258. internet.c 1256
- V595 The 'name' pointer was utilized before it was verified against nullptr. Check lines: 125, 133. hash.c 125
- V595 The 'oldctxt' pointer was utilized before it was verified against nullptr. Check lines: 13444, 13448. parser.c 13444
- V595 The 'oldctxt' pointer was utilized before it was verified against nullptr. Check lines: 13675, 13693. parser.c 13675
- V595 The 'optarg' pointer was utilized before it was verified against nullptr. Check lines: 645, 646. tnconfig.cpp 645
- V595 The 'pData' pointer was utilized before it was verified against nullptr. Check lines: 239, 255. clipboard.c 239
- V595 The 'pMapper' pointer was utilized before it was verified against nullptr. Check lines: 938, 965. createdevenum.c 938
- V595 The 'pThis' pointer was utilized before it was verified against nullptr. Check lines: 1368, 1375. atlwin.h 1368
- V595 The 'pThis' pointer was utilized before it was verified against nullptr. Check lines: 1550, 1557. atlwin.h 1550
- V595 The 'param' pointer was utilized before it was verified against nullptr. Check lines: 535, 537. effect.c 535
Неинициализированная переменная
| C++ | 1
2
3
4
5
6
7
8
9
10
11
| static HRESULT parse_canonicalize(....)
{
const WCHAR **pptr;
....
if(uri->scheme_start > -1 && uri->path_start > -1) {
ptr = uri->canon_uri+uri->scheme_start+uri->scheme_len+1;
pptr = &ptr;
}
reduce_path = !(flags & URL_DONT_SIMPLIFY) &&
ptr && check_hierarchical(pptr);
} |
|
В случае невыполнения условия переменная pptr окажется неинициализированной на момент использования функции check_hierarchical.
Похожие ошибки также обнаружены в других местах:
- V614 Potentially uninitialized pointer 'name' used. Consider checking the third actual argument of the 'disp_get_id' function. engine.c 928
- V614 Potentially uninitialized pointer 'name_str' used. Consider checking the first actual argument of the 'jsstr_release' function. engine.c 929
- V614 Potentially uninitialized pointer 'FileHandle' used. Consider checking the first actual argument of the 'CloseHandle' function. dosfiles.c 402
- V614 Potentially uninitialized pointer 'FileHandle' used. Consider checking the first actual argument of the 'CloseHandle' function. dosfiles.c 482
- V614 Potentially uninitialized pointer 'pwszClsid' used. Consider checking the third actual argument of the 'RegGetValueW' function. cfsfolder.cpp 1666
- V614 Potentially uninitialized pointer 'FilePart' used. smutil.c 405
Побитовое сравнение
| C++ | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| typedef enum CorTokenType
{
mdtModule = 0x00000000,
mdtTypeRef = 0x01000000,
....
mdtModuleRef = 0x1a000000,
mdtTypeSpec = 0x1b000000,
mdtAssembly = 0x20000000,
mdtAssemblyRef = 0x23000000,
....
} CorTokenType;
#define TypeFromToken(tk) ((ULONG32)((tk) & 0xff000000))
#define TableFromToken(tk) (TypeFromToken(tk) >> 24)
static inline ULONG get_table_size(....)
{
INT tables;
....
tables = max(
assembly->tables[TableFromToken(mdtModule)].rows, //<-
assembly->tables[TableFromToken(mdtModuleRef)].rows);
....
} |
|
В приведённом примере видно, как побитовое сравнение происходит с изначально нулевой константой. Результатом операции всегда является нулевое значение, и данное сравнение не имеет смысла.
Заключение
ReactOS - это постоянно развивающийся проект. В таких проектах может скапливаться большое количество ошибок. Регулярный статический анализ с помощью PVS-Studio поможет выявить не только уже существующие ошибки, но и подозрительные места, в которых они могут появиться в будущем.
|
