Resx resy что это
Широкоэкранное разрешение
ктото писал что в файлах конфигурации вписать свое разрешение, но никто толком необяснит где ети файлы и куда вписевать.
Х:\папка трона\Engine\Config\BaseEngine.ini
раздел [SystemSettings]
E:\Users\\Documents\Disney Interactive Studios\Tron Evolution\UnrealEngine3\GridGame\Config
находите там файл GridEngine.ini, запускайте и далее ищите 2 строчки
Меняйте на своё разрешение и сохраняйте)
ура)) у меня наконецто заработало 1920х1080. клас)) совсем другой вид приобрела игра)) расказую как именно я сделал))
Работа с RESX-файлами программным способом
Здесь рассматривается работа с XML-файлами (RESX-файлами), содержащими ресурсы. Сведения о работе с двоичными файлами ресурсов, внедренными в сборки, см. в статье ResourceManager.
Существуют также способы работы с RESX-файлами, отличные от программных. При добавлении в проект Visual Studio файла ресурсов среда Visual Studio предоставляет интерфейс для создания и обслуживания RESX-файла и во время компиляции автоматически преобразует RESX-файл в RESOURCES-файл. Для непосредственной работы с RESX-файлом можно также использовать текстовый редактор. Однако следует соблюдать осторожность и избегать изменения содержащихся в файле двоичных данных: это может привести к его повреждению.
Создание RESX-файла
Вызовите метод ResXResourceWriter.AddResource для каждого ресурса, который необходимо добавить в файл. Используйте перегрузки этого метода для добавления строки, объекта и двоичных данных (массива байтов). Если ресурсом является объект, он должен быть сериализуемым.
Не следует использовать файлы ресурсов для хранения паролей, конфиденциальной информации или личных данных.
Для создания RESX-файлов можно также использовать Visual Studio. Во время компиляции Visual Studio использует генератор файлов ресурсов (Resgen.exe) для преобразования RESX-файла в двоичный файл ресурсов (RESOURCES-файл) и внедряет этот файл в сборку приложения или вспомогательную сборку.
RESX-файл нельзя внедрить в исполняемый файл или скомпилировать во вспомогательную сборку. Необходимо преобразовать RESX-файл в двоичный файл ресурсов (RESOURCES-файл) с помощью генератора файлов ресурсов (Resgen.exe). Затем полученный RESOURCES-файл можно внедрить в сборку приложения или вспомогательную сборку. Дополнительные сведения см. в разделе Создание файлов ресурсов.
Перечисление ресурсов
Получение определенного ресурса
Преобразование RESX-файлов в двоичные RESOURCES-файлы
Преобразование RESX-файлов во внедряемые двоичные файлы ресурсов (RESOURCES-файлы) имеет значительные преимущества. Хотя RESX-файлы легко читаются и обслуживаются при развертывании приложения, они редко поставляются с готовыми приложениями. Если они распространяются с приложением, то существуют в виде отдельных файлов наряду с исполняемым файлом приложения и сопровождающими его библиотеками. В отличие от RESX-файлов RESOURCES-файлы внедряются в исполняемый файл приложения или сопровождающие его сборки. Кроме того, если локализованные приложения полагаются на RESX-файлы во время выполнения, это означает, что ответственность за обработку перехода к другим ресурсам несет разработчик. Напротив, если создан ряд вспомогательных сборок, содержащих внедренные RESOURCES-файлы, процесс перехода на резервные ресурсы обрабатывается средой CLR.
Для преобразования RESX-файла в RESOURCES-файл используется генератор файлов ресурсов (resgen.exe), который имеет следующий базовый синтаксис:
Результат — двоичный файл ресурсов, который имеет такое же корневое имя файла, что и RESX-файл, и расширение RESOURCES-файла. Затем во время компиляции этот файл может быть компилирован в исполняемый файл или библиотеку. Если применяется компилятор Visual Basic, для внедрения RESOURCES-файла в исполняемый файл приложения используйте следующий синтаксис:
Как найти 56 потенциальных уязвимостей в коде FreeBSD за один вечер
О проверке
Отчет о нашей проверке FreeBSD в 2016 году можно посмотреть здесь.
Как следует из названия, то, что будет описано в статье, я нашел за один вечер. Т.е. на поиск потенциальных уязвимостей я потратил всего 2-3 часа. Это говорит о всей мощи статического анализатора PVS-Studio. Я рекомендую использовать наш анализатор всем, кого заботит качество кода, а тем более его надёжность и устойчивость к возможным атакам.
Выписал код с ошибками я быстро, а вот найти время оформить свои изыскания в виде этой статьи я не мог три недели. За это время мы даже поправили некоторые из ошибок, которые будут описаны в статье, в рамках нового направления «Дефекты безопасности, которые устранила команда PVS-Studio на этой неделе»: выпуск N2, выпуск N3.
Правили мы то, что попроще и где понятно, как поправить, не вдаваясь в суть алгоритмов. Поэтому авторам FreeBSD не стоит ограничиваться нашими правками и даже этой статьей, а имеет смысл провести анализ кода самостоятельно и более подробно. Я готов выдать им временный ключ для полноценной проверки, а также помочь в борьбе с ложными срабатываниями, которые будут им мешать. Кстати, о ложных срабатываниях…
Ложные срабатывания
Проверив проект с помощью PVS-Studio, можно получить очень большой разброс по количеству ложных срабатываний. Например, мы недавно проверяли проект FAR, и количество ложных срабатываний составило 50%. Это отличный результат, означающий, что каждое второе сообщение указывает на ошибку или крайне плохой код. А при проверке Media Portal 2 результат был ещё лучше: 27% ложных срабатываний.
С проектом FreeBSD всё сложнее. Дело в том, что анализатор выдал огромное количество предупреждений общего назначения:
О чем это говорит? Это говорит, что нет смысла рассуждать о количестве ложных срабатываний на больших проектах, не проведя предварительную настройку анализатора. Большинство ложных предупреждений возникает из-за разных макросов и их легко убрать, используя различные механизмы, предусмотренные в PVS-Studio. Поясню это на примере.
В коде FreeBSD можно встретить вот такой массив:
Макрос Q(1.5) раскрывается в:
Некоторые из сравнений анализатор PVS-Studio считает подозрительными. Например, на выражение (((1.5) == 3) он выдаёт предупреждение:
V674 The ‘1.5’ literal of the ‘double’ type is compared to a value of the ‘int’ type. Consider inspecting the ‘(1.5) == 3’ expression. tx_schedules.h 228
Всего на этот массив анализатор выдаёт 96 сообщений.
В коде FreeBSD можно встретить ещё несколько таких массивов. Суммарно анализатор выдаёт на них 692 предупреждения уровня High. Напомню, что всего предупреждений уровня High насчитывается 3577. Это значит, что такие макросы приводят к возникновению 1/5 этих предупреждений.
Другими словами, чуть-чуть настроив анализатор, можно устранить 20% ложных сообщений уровня High. Сделать это можно по-разному, но, пожалуй, проще всего будет выключить предупреждение V674 для тех файлов, в которых используются подобные массивы. Для этого нужно написать где-то в файле комментарий //-V::674.
Я уже озвучивал важную мысль, но повторю её, так как нас вновь и вновь спрашивают о среднем проценте ложных срабатываний. Даже если мы посчитаем этот средний процент на основании проверки многих проектов, он не будет иметь никакой практической ценности. Это тоже самое, как интересоваться средней температурой по больнице.
Все очень сильно зависит от проекта. Кому-то повезёт и можно работать со списком предупреждений, практически ничего не настраивая. Другим не повезёт, как в случае с проектом FreeBSD. Придётся заниматься настройкой и разметкой макросов. Но это не так страшно, как может показаться на первый взгляд. Выше я как раз показал, каким образом сразу можно устранить много ложных предупреждений. Аналогичная ситуация будет и с другими предупреждениями, возникающими из-за дурацких макросов.
Да и вообще, если бы с шумом было сложно бороться, я бы не смог найти все эти ошибки для статьи за один вечер.
Новый взгляд на мир
Мы решили смотреть на мир более широко. Там, где раньше мы видели ошибки и код с запахом, теперь мы стараемся видеть ещё и потенциальные уязвимости. Для этого мы решили начать с того, что будем классифицировать предупреждения, выдаваемые с помощью PVS-Studio согласно Common Weakness Enumeration (CWE). Подробнее про это можно почитать здесь: PVS-Studio: поиск дефектов безопасности.
Конечно, только малую часть ошибок можно эксплуатировать. Другими словами, только немногие из найденных CWE ошибок могут превратиться в CVE. Однако, чем больше ошибок, попадающих под классификацию CWE, будет найдено с помощью статического анализа, тем лучше.
Используйте PVS-Studio для профилактики уязвимостей. Эта статья продемонстрирует, что анализатор хорошо справляется с этой задачей.
Потенциальные уязвимости
CWE-476: NULL Pointer Dereference
Всего я заметил 22 ошибки этого типа. И, наверное, ещё столько же пропустил.
Давайте начнем с простого случая.
Предупреждение PVS-Studio: V522 Dereferencing of the null pointer ‘ha’ might take place. ql_isr.c 750
Здесь ошибка видна сразу. Если указатель ha равен NULL, то он разыменовывается в выражении ha->pci_dev.
Такая же ситуация обнаруживается ещё в трёх файлах:
Предупреждение PVS-Studio: V595 The ‘ilt’ pointer was utilized before it was verified against nullptr. Check lines: 667, 669. ecore_init_ops.h 667
На этом случае остановимся поподробнее, так как далеко не все понимают всю опасность, которая заключена в этом коде.
В начале указатель ilt разыменовывается:
Далее он проверяется на равенство NULL:
Следовательно, возможно разыменование нулевого указателя. Это неизбежно приводит к неопределённому поведению программы.
Здесь некоторые возразят, что никакой беды нет, так как указатель разыменовывается «не по-настоящему». Они скажут, что просто вычисляется адрес ячейки массива. Да, скажут они, этот адрес некорректен и его использовать нельзя. Однако, ниже есть проверка, и произойдёт выход из функции, если указатель ilt будет равен нулю. Следовательно, невалидный указатель ilt_cli не будет нигде использоваться и никакой ошибки в программе нет.
Они не правы. Нельзя так размышлять. Разыменование нулевого указателя приводит к неопределенному поведению. Следовательно, код некорректен и не следует рассуждать, как он будет работать. Он может работать как угодно.
Однако, такое объяснение часто не устраивает некоторых читателей, поэтому я попробую развить мысль. Компилятор знает, что разыменование нулевого указателя — это неопределённое поведение. Следовательно, если указатель разыменовывают, то он не равен NULL. Раз он не равен NULL, компилятор имеет полное право удалить избыточную проверку if (!ilt). В результате, если указатель будет равен NULL, то из функции не произойдёт выход. Поэтому функция начнет обрабатывать невалидные указатели, что может привести к чему угодно.
Некоторые возражают, говоря, что макрос offsetof иногда реализуют следующим образом:
Здесь имеет место разыменование нулевого указателя, но код успешно работает. Следовательно, это доказывает, что подобные конструкции вполне допустимы.
И вновь они не правы. Ничего это не доказывает.
При рассмотрении идиоматической реализации offsetof следует учитывать, что компилятору разрешено использовать непереносимые приемы для реализации этой функциональности. Тот факт, что в реализации библиотеки в компиляторе используется константа нулевого указателя при реализации offsetof, вовсе не означает, что в пользовательском коде можно без опаски выполнять &ilt->clients[cli_num] в случае, когда ilt является нулевым указателем.
В итоге, рассмотренный выше код представляет собой самую настоящую ошибку и должен быть исправлен.
Теперь, когда мы разобрались с нюансами разыменования нулевого указателя, становится понятно, что неправильной является и следующая функция:
Предупреждение анализатора PVS-Studio: V522 Dereferencing of the null pointer ‘ccb’ might take place. The null pointer is passed into ‘iscsi_outstanding_add’ function. Inspect the third argument. Check lines: ‘iscsi.c:2157’. iscsi.c 2091
В начале может быть не понятно, почему анализатор решил, что указатель ccb будет нулевым. Поэтому обратим внимание, что анализатор указывает в предупреждении ещё и вот сюда: iscsi.c:2157.
Здесь находится вызов функции iscsi_outstanding_add, в которую в качестве фактического аргумента передаётся NULL:
Здесь анализатору понадобилось выполнить межпроцедурный анализ, чтобы найти дефект.
Немного отдохнем от сложных ошибок и рассмотрим совсем простой случай неправильного обработчика ошибок.
Предупреждение анализатора PVS-Studio: V522 Dereferencing of the null pointer ‘dev_priv’ might take place. radeon_cs.c 153
Тело оператора if выполняется только когда указатель dev_priv равен нулю. Таким образом, здесь вычисляется непонятно какой адрес: &dev_priv->cs.cs_mutex. Да и вообще это UB.
Ох. Что-то проблемы с нулевыми указателями никак не заканчиваются. Но что делать, раз это головная боль многих языков программирования. Так что заварите кофе и продолжайте чтение.
Предупреждение анализатора PVS-Studio: V595 The ‘mac’ pointer was utilized before it was verified against nullptr. Check lines: 6757, 6760. if_bwn.c 6757
Указатель mac в начале разыменовывается, а далее проверяется на равенство NULL. Здесь всё просто, так что подробнее комментировать не буду.
Предупреждение анализатора PVS-Studio: V595 The ‘ctl3_rewriters’ pointer was utilized before it was verified against nullptr. Check lines: 3206, 3210. ip_fw_sockopt.c 3206
Обратите внимание, что вначале указатель ctl3_rewriters используется как фактический аргумент функции memcpy:
А затем вдруг вспоминают, что его следует проверять на равенство NULL:
Рассмотрим ещё один случай неправильного кода, предназначенного для освобождения ресурсов:
Предупреждение анализатора PVS-Studio: V595 The ‘mc’ pointer was utilized before it was verified against nullptr. Check lines: 2954, 2955. mly.c 2954
Стоит закругляться с нулевыми указателями, так как, думаю, описание таких ошибок уже наскучило не только мне, но и читателю. Я вижу CWE-476 (NULL Pointer Dereference) ещё в следующих участках кода:
CWE-467: Use of sizeof() on a Pointer Type
Рассмотрим определение структуры pfloghdr:
Как видите, такая структура достаточно большая. Для инициализации подобных структур распространена практика, когда вся структура заполняется нулями, а потом устанавливаются значения для отдельных полей.
Однако, в функции nat64lsn_log не удалось корректно произвести инициализацию структуры. Рассмотрим код этой функции:
Предупреждение анализатора PVS-Studio: V512 A call of the ‘memset’ function will lead to underflow of the buffer ‘plog’. nat64lsn.c 218
Обратите внимание, что sizeof(plog) вычисляет не размер структуры, а размер указателя. В результате обнуляется не вся структура, а только несколько первых байт, все остальные поля структуры остаются неинициализированными. Конечно, в некоторые поля затем явно записываются правильные значения. Однако, ряд членов в структуре останется неинициализированными.
Точно такую же ошибку можно наблюдать в файле nat64stl.c: V512 A call of the ‘memset’ function will lead to underflow of the buffer ‘plog’. nat64stl.c 72
CWE-457: Use of Uninitialized Variable
Рассмотрим ещё одну ошибку, из-за которой переменная может быть не инициализирована.
Предупреждение анализатора PVS-Studio: V614 Uninitialized variable ‘status’ used. tdioctl.c 3396
Если объявлен макрос __FreeBSD__ (а он объявлен), то условие
не выполняется. Как результат, код внутри конструкции #if. #endif не компилируется, и переменная status остаётся неинициализированной.
CWE-805: Buffer Access with Incorrect Length Value
Предупреждение анализатора PVS-Studio: V512 A call of the ‘memcpy’ function will lead to the ‘«MPI Coredump»’ buffer becoming out of range. qls_dump.c 1615
Чтобы показать, как объявлены интересующие нас типы и члены структуры, пришлось привести достаточно много кода. Но не спешите зевать, сейчас я выделю самое существенное:
CWE-129: Improper Validation of Array Index
Вот и представился случай продемонстрировать вам одну из новых диагностик, реализованных в PVS-Studio. Суть диагностики V781:
В начале значение переменной используется в качестве размера или индекса массива. А уже затем это значение сравнивается с 0 или с размером массива. Это может указывать на наличие логической ошибки в коде или опечатку в одном из сравнений.
По своей сути эта диагностика схожа с V595, которая хорошо знакома моим постоянным читателям.
Предупреждение анализатора PVS-Studio: V781 The value of the ‘lun’ variable is checked after it was used. Perhaps there is a mistake in program logic. Check lines: 1617, 1619. sbp_targ.c 1617
В начале программист смело использовал индекс lun для доступа к массиву lstate. И только затем осуществляется проверка: не превышает ли значение индекса предельно допустимое значение, равное MAX_LUN? Если превышает, то эта ситуация обрабатывается как ошибочная. Но уже поздно, так как мы уже могли обратиться далеко за пределы массива.
Формально, это приведёт к неопределённому поведению программы. На практике, вместо корректной обработки неправильного значения индекса может возникнуть Access Violation.
Теперь рассмотрим более интересный случай неправильной индексации массива.
Анализатор выдал здесь три предупреждения на три выражения, где осуществляется доступ к массиву pwr:
Чтобы найти ошибку, обратим внимание на член pwr, представляющий собой двухмерный массив:
И давайте ещё раз посмотрим, как происходит доступ к этому массиву в цикле:
Здесь явно что-то не так. Происходит выход за границу массива. Однако, я затрудняюсь предположить, как должен работать этот код и что здесь следует изменить.
CWE-483: Incorrect Block Delimitation
Предупреждение анализатора PVS-Studio: V640 The code’s operational logic does not correspond with its formatting. The statement is indented to the right, but it is always executed. It is possible that curly brackets are missing. smbfs_vnops.c 283
Оформление кода не соответствует логике его работы. Визуально кажется, что строчка smbfs_free_scred(scred); выполняется только, если условие истинно. Но на самом деле, эта сточка выполняется всегда.
Возможно, настоящей ошибки здесь нет, и достаточно отформатировать код, но, в любом случае, этот фрагмент кода заслуживает самого пристального внимания.
Анализатор выявил ещё 4 четыре аналогичных подозрительных фрагмента кода, но не буду их здесь приводить, так как они все однотипны. Ограничусь предупреждениями:
CWE-563: Assignment to Variable without Use (‘Unused Variable’)
Предупреждение анализатора PVS-Studio: V519 The ‘a1’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 397, 400. ip_ftp_pxy.c 400
Независимо от условия, переменной a1 будет присвоено значение ntohl(ip->ip_src.s_addr).
Мне кажется, что последнее присваивание является лишним. Возможно, такой код получился в результате неудачного рефакторинга.
Продолжим рассмотрение ошибок этой разновидности:
Предупреждение анализатора PVS-Studio: V519 The ‘rdata->sd_vlan_force_pri_flg’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 6327, 6328. ecore_sp.c 6328
Ситуация аналогичная, так что не будем на ней останавливаться. Идём дальше.
Предупреждение анализатора PVS-Studio: V519 The ‘vf->flags’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 5992, 5994. if_ix.c 5994
Скорее всего пропустили «|» и корректный код должен был быть таким:
Вообще, все эти ошибки, которые я рассматриваю, пугают. Точнее, их количество. Ведь я вижу, сколько ошибок выписал, и что конец статьи не близок.
Предупреждение анализатора PVS-Studio: V519 The ‘lmask.__mask’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 594, 595. linux32_sysvec.c 595
Предупреждение анализатора PVS-Studio: V519 The ‘sysctl_log_level’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 423, 424. alias_sctp.c 424
Видимо код писался методом Copy-Paste, и, как всегда, имя самой последней переменной забыли поменять. Следовало написать:
См. философско-исследовательскую статью на эту тему: «Объяснение эффекта последней строки».
Продолжим изучать, как глубока кроличья нора.
Предупреждение анализатора PVS-Studio: V519 The ‘chunk->flags’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1566, 1567. if_uath.c 1567
Пора вставить какую-то картинку для расслабления и отдыха. Думаю, эта как раз подойдёт.
Предупреждение анализатора PVS-Studio: V519 The ‘lvds_pll_feedback_div’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 287, 290. dvo_ch7017.c 290
Перетирать значение переменной магическим числом 35 ну очень странно и подозрительно. Похоже, что кто-то написал эту строчку в отладочных целях, а потом забыл её удалить.
Предупреждение анализатора PVS-Studio: V519 The ‘pmuctrl’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 2025, 2026. bhnd_pmu_subr.c 2026
Вместо оператора |= случайно написали =.
И последний, на сегодня, дефект этого типа:
Предупреждение анализатора PVS-Studio: V519 The ‘msgbuf[0]’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 422, 426. e1000_vf.c 426
CWE-570: Expression is Always False
Предупреждение анализатора PVS-Studio: V547 Expression is always false. scif_sas_controller.c 531
Переменная не может быть одновременно меньше 1 и больше 32. Чтобы корректно проверить диапазон, нужно заменить оператор && на оператор ||.
Из-за ошибки функция не проверяет входные значения и может работать с некорректными данными.
Теперь более интересный случай. Для начала рассмотрим прототип функции LibAliasSetMode:
Теперь посмотрим, как используется эта функция.
Я не знаю, может ли эта неправильная проверка вызвать сбой или циклы в любом случае будут корректно прерваны, благодаря наличию в их телах операторов break и return. Мне кажется, это настоящий баг и стоит изменить тип переменной j с u_int на int.
Если даже ошибки здесь нет, то код стоит переписать, чтобы он не сбивал с толку других разработчиков и не стал в дальнейшем причиной проблемы, когда кто-то будет изменять этот код.
Лично мне нравится ошибка, описанная ниже. Это красивая опечатка. Хотя нет, стоп, я же решил в этот раз говорить про CWE. Итак, перед нами красивая потенциальная уязвимость:
Предупреждение анализатора PVS-Studio: V560 A part of conditional expression is always true: 0x2002. sampirsp.c 7224
В условии один раз пропущена переменная status. Таким образом, значение статуса на самом деле не проверяется, и условие всегда истинно.
Рассмотрим ещё один аналогичный случай. Попробуйте, не читая описание, найти ошибку в функции ugidfw_rule_valid самостоятельно.
Думаю, да. Вот поэтому статические анализаторы так важны. Они не зевают и не устают при просмотре подобных функций.
Предупреждение анализатора PVS-Studio: V617 Consider inspecting the condition. The ‘0x00000080’ argument of the ‘|’ bitwise operation contains a non-zero value. mac_bsdextended.c 128
Для начала, взглянем на макрос MBO_TYPE_DEFINED:
А теперь, смотрим вот сюда:
Часть условия всегда истина. Если посмотреть код, расположенный рядом, то становится понятным, что на самом деле, хотели написать вот так:
Что-то статья всё не хочет заканчиваться. Придётся немного ускориться и сократить количество фрагментов кода. Так что просто знайте, что вижу ещё четыре CWE-571:
CWE-14: Compiler Removal of Code to Clear Buffers
Предупреждение анализатора PVS-Studio: V597 The compiler could delete the ‘memset’ function call, which is used to flush ‘dout’ object. The memset_s() function should be used to erase the private data. mlx5_qp.c 159
Хотели обнулить структуру dout, содержащую приватные данные. Ошибка в том, что эта структура в дальнейшем не используется. Точнее, она используется вот здесь sizeof(dout), но это не считается. Поэтому компилятор удалит вызов функции memset.
Ещё одно неудачное обнуление структуры можно найти здесь: V597 The compiler could delete the ‘memset’ function call, which is used to flush ‘dout’ object. The memset_s() function should be used to erase the private data. mlx5_qp.c 323
Каждый раз, когда я описываю ошибку обнуления приватных данных, находится кто-то, кто пишет мне одно из двух сообщений:
CWE-561: Dead Code
Предупреждение анализатора PVS-Studio: V779 Unreachable code detected. It is possible that an error is present. if_wi_pci.c 258
В начале в тексте программы расположен оператор return, а затем происходит попытка разлочить некий ресурс.
Прочее
Я нашел ещё десяток занятных багов в коде. Я не знаю, как их классифицировать согласно CWE, поэтому не буду считать их за потенциальные уязвимости, но все равно опишу. Ведь независимо от того, могу я их классифицировать или нет, ошибки всё равно остаются ошибками.
Предупреждение анализатора PVS-Studio: V646 Consider inspecting the application’s logic. It’s possible that ‘else’ keyword is missing. mac_process.c 352
Мне, как и анализатору, кажется, что здесь забыли ключевое слово else.
Предупреждение анализатора PVS-Studio: V778 Two similar code fragments were found. Perhaps, this is a typo and ‘cap_resy’ variable should be used instead of ‘cap_resx’. cyapa.c 1458
Здесь забыли поменять cap_resx на cap_resy.
Предупреждение анализатора PVS-Studio: V523 The ‘then’ statement is equivalent to the ‘else’ statement. linux_ipc.c 353
Предупреждение анализатора PVS-Studio: V666 Consider inspecting third argument of the function ‘strncmp’. It is possible that the value does not correspond with the length of a string which was passed with the second argument. ip_irc_pxy.c 140
Обратите внимание, что в начале проверяется, начинается ли строка с символов «PRIVMSG ». При этом учитывается пробел.
Далее идёт проверка, что строка начинается с «\001DCC «. Но в этой строке, если считать пробел, не 4, а 5 символов. Примечание: \001 — это один символ.
Пришло время PVS-Studio
Код FreeBSD регулярно проверяется с помощью Coverity (который теперь стал частью Synopsys). Это не помешало мне сесть вечером на стул, запустить PVS-Studio и найти за вечер 56 потенциальных уязвимостей и ещё 10 багов. Причем я совершенно не ставил цель найти как можно больше ошибок. О чем это говорит? О том, что PVS-Studio является серьёзным конкурентом Coverity в диагностических возможностях. Да ещё PVS-Studio и стоит при этом дешевле.
Заключение
Традиционно повторю, что статический анализатор должен использоваться не от случая к случаю, а регулярно. Единичная проверка, подобная той, что описана в статье, может служить хорошей рекламой анализатора, но не принесёт проверенному проекту существенной пользы. Вся суть статического анализа, что многие ошибки можно исправить на самом раннем этапе. Дополнительно, так легче поддерживать вывод анализатора чистым и не искать ошибки среди сотен ложных срабатываний. Здесь полная аналогия с предупреждениями компилятора.
Поэтому хватит читать статьи, пора начинать использовать PVS-Studio на практике. Поэтому предлагаю, не откладывая скачать PVS-Studio и попробовать проверить свои проекты. По вопросам лицензирования, пишите на почту support[@]viva64.com или воспользуйтесь формой обратной связи.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. How to find 56 potential vulnerabilities in FreeBSD code in one evening