https://slinkov.ru/openforum/vsluhforumID3/110879.html Разработчики PVS-Studio (http://www.viva64.com/ru/pvs-studio/), коммерческого статического анализатора кода на языках C, C++ и C#, опубликовали (https://www.viva64.com/ru/b/0496/) результаты инициативы по проверке кода FreeBSD с целью выявления потенциальных уязвимостей. В итоге было найдено 56 ошибок, которые не исключено, что могут привести к проблемам с безопасностью. Проверка при помощи автоматизированного инструмента не заняла много времени, что позволило обнаружить все эти ошибки лишь за один субботний вечер.<br><br><br>Всего в коде выявлено 22 ошибки, которые могут привести к проблемам из-за разыменования нулевого указателя, а также ошибки вызванные некорректным использованием sizeof() с указателями, использованием неинициализированных переменных, некорректным указанием размера буфера, неверной организацией проверки индекса массива, подозрительным использованием разделителей в блоках кода, наличием неиспользуемых переменных, всегда ложными или истинными логическими выражениями, удалением компилятором кода для https://slinkov.ru/openforum/vsluhforumID3/110879.html#180 Thu, 13 Apr 2017 12:43:59 GMT P.S.<br><br>Мы перепроверили с помощью PVS-Studio свежую версию исходных кодов проекта FreeBSD. Git revision: 59fe28863e6a0903b50b37c616f21a2a865bbbf2<br><br>Мы немного поработали с отчетов, отфильтровав явно лишние на наш взгляд сообщения. В списке конечно всё равно осталось много ложных срабатываний, но дальше уже нет возможности убирать лишние предупреждения крупными группами. Оставшиеся предупреждения следует смотреть по отдельности.<br><br>Отчет выкладываем в двух форматах (tasks и csv). Тому, кто будет работать с отчетом в начале следует произвести автоматическую замену SOURCE_ROOT на нужный путь, чтобы правильно начала работать навигация.<br><br>Tasks: http://cppfiles.com/freebsd.plog.tasks<br><br>Csv: http://cppfiles.com/freebsd.plog.csv<br><br>Готовы помочь чем сможем и ответить на любые вопросы.<br> https://slinkov.ru/openforum/vsluhforumID3/110879.html#179 Thu, 13 Apr 2017 01:47:16 GMT &gt; конечно. Кто ж на совершенно обезьянью работу будет нанимать кого-то более дорогостоящего?<br><br>Чего там нужно такого дорогостоящего в знании того, где находится gcc на платформе? Её достаточно просто использовать. Я понимаю, патчи к этому gcc писать. Что, впрочем, тоже не высшая математика.<br><br>&gt; И с чего, кстати, 3-d party не-gpl компилятору быть "потенциально базовым пакетом" хотя бы в отдаленной перспективе?<br><br>А с чего бы и нет? Какие, собственно, препятствия? Для дистрибутива gcc ровно такой же 3-d party.<br><br>&gt; я предложил вам глянуть на другой софт, тоже вынужденный определять тип системы, чтобы знать, как ему устанавливаться.<br><br>Ну и? Ещё один пример диковатых людей, пришедших с системы, не обладающей пакетным менеджером и репозитариями. Я же говорю, что типичный ИТшник - человек дремучий. apt-get был ещё в 1998-м, а dselect ещё раньше. Однако же многие до сих пор делают windows-style инсталляшки, тот же Wolfram с Mathematica. Ну что с них взять? Хорошо хоть без вирусов.<br><br>&gt; Вы, похоже, ни одного слова не https://slinkov.ru/openforum/vsluhforumID3/110879.html#178 Tue, 11 Apr 2017 14:17:16 GMT &gt; Вспомнилось ещё одно насчёт подзабытого скилла содержания разных gcc на хосте<br><br>судя по названиям пакетов, скилл таки забыт, просто destdir с некоторыми не совсем приятными последствиями в виде намертво вбитых путей к libgcc/libstdc++, отличающихся от общепринятых.<br>&gt; Даже для спеков есть обвязка в виде %set_gcc_version<br><br>так вот правильный скилл позволял выбирать компилятор через, сюрприз, CFLAGS!<br>(есть/был такой интересный ключик -V и -b еще. с последним я, правда, не подружился)<br><br> https://slinkov.ru/openforum/vsluhforumID3/110879.html#177 Tue, 11 Apr 2017 07:49:41 GMT &gt; LLVM сейчас - часть<br>&gt;Под него заточена инфраструктура DRM, <br><br>Тебе-то, понятно, без разницы - натачиваешь свой эпплекомпайлер, но--<br><br>&gt; % pkg info -dr dri-13.0.6,2 <br>&gt; dri-13.0.6,2 <br><br>"DRM" != "DRI" //https://dri.freedesktop.org/wiki/DRM/#inwhatwaydoesthedrmsupportthedri<br><br> https://slinkov.ru/openforum/vsluhforumID3/110879.html#176 Mon, 10 Apr 2017 16:51:47 GMT &gt;&gt; с проектами уровня llvm (с которого начался разговор) - ну я вот <br>&gt;&gt; видел один раз в _одном_ дистрибутиве майнтейнера, который понимал как работает <br>&gt;&gt; (сборка, а не как вызывать уже кем-то собранный) gcc в деталях, <br>&gt;&gt; но это было давно, ему наверняка давно уже надоело.<br>&gt; Не буду расхваливать, но у нас его вроде как тоже довольно неплохо <br>&gt; понимают; при этом llvm в проекте довольно внимательно занимаются тоже два <br>&gt; разных человека.<br><br>LLVM сейчас - часть графической подсистемы *nix. Под него заточена инфраструктура DRM, X.org Server:<br><br>% pkg info -dr dri-13.0.6,2<br>dri-13.0.6,2<br>Depends on :<br>libxshmfence-1.2_1<br>libXxf86vm-1.1.4_1<br>libXvMC-1.0.10<br>libXv-1.0.11,1<br>libXfixes-5.0.3<br>libXext-1.3.3_1,1<br>libXdamage-1.1.4_3<br>libX11-1.6.5,1<br>expat-2.2.0_1<br>libdrm-2.4.78,1<br>llvm39-3.9.1_4<br>Required by :<br>xorg-server-1.18.4,1<br> https://slinkov.ru/openforum/vsluhforumID3/110879.html#174 Mon, 10 Apr 2017 12:46:34 GMT &gt;&gt;&gt; "майнтейнер" - обычный мидсаммер стьюдент, ничего он о дистрибутиве не знает <br>&gt;&gt; Зависит.<br>&gt; тот который знает (за пределами наспех прочитанных методичек) - уже давно<br>&gt; эффективный менеджер, у него нет времени самому собирать сложные пакеты <br><br>Зависит... но народ продолжаем набирать, да.<br><br>&gt; напоминаю, первые выдернутые из моей памяти примеры: virtualbox<br><br>У нас и его текущий майнтейнер весьма лазит внутрь, и предыдущий (который из проекта никуда не девался, но последний год или около того ударно занимается самбовыми потрохами).<br><br>&gt; И если с первым еще при желании (а откуда оно возьмется?) разберешься (хотя правильней<br>&gt; для дистрибутива потратить это время на разборки с его http-интерфейсом, кластеризацией<br>&gt; и 3d-party мордами, чтобы это все уинтегрировать правильно - пользователи оценят)<br><br>А вот здесь можно и потратить время на FR вида ТЗ при желании. В идеале бы сразу в bugzilla.altlinux.org, но можно и мне в почту.<br><br>&gt; с проектами уровня llvm (с которого начался разговор) - ну я вот <br>&gt; видел о https://slinkov.ru/openforum/vsluhforumID3/110879.html#173 Mon, 10 Apr 2017 12:31:33 GMT &gt;&gt; кому должен и когда этот кто-то успел в такие долги вляпаться?<br>&gt; Разработчики дистрибутива. В момент создания дистрибутива.<br><br>это вы о ком, о миллионере Марке Эвинге (the guy in red baseball hat)? Ему уже давно похрен ваши проблемы, он вам не должен, хотя нормально на лохах денег поднял.<br>ЛаРош миллионером, кажется, так и не стал, и ушел куда-то в туман, вряд ли он будет вам пересобирать пакеты единственноправильным образом.<br>Кто там был в дебиане, не помню, за неинтересностью, но они вообще ничего не умели.<br><br>&gt;&gt; "майнтейнер" - обычный мидсаммер стьюдент, ничего он о дистрибутиве не знает <br>&gt; Это в RH, OpenSuse или Debian'е, сборщик потенциально БАЗОВОГО пакета? У вас <br><br>конечно. Кто ж на совершенно обезьянью работу будет нанимать кого-то более дорогостоящего?<br>И с чего, кстати, 3-d party не-gpl компилятору быть "потенциально базовым пакетом" хотя бы в отдаленной перспективе?<br><br>&gt; какие-то дикие представления о современных Линуксах.<br><br>это у вас какие-то фантастические, что ЛаРош лично вам по сей день тща https://slinkov.ru/openforum/vsluhforumID3/110879.html#172 Mon, 10 Apr 2017 12:07:20 GMT &gt;&gt; "майнтейнер" - обычный мидсаммер стьюдент, ничего он о дистрибутиве не знает<br>&gt; Зависит.<br><br>тот который знает (за пределами наспех прочитанных методичек) - уже давно эффективный менеджер, у него нет времени самому собирать сложные пакеты<br><br>&gt;&gt; Они и о собираемой программе чаще всего не знают нишиша.<br>&gt; Вот это более обычное дело, если человек не разработчик собираемой программы или не<br>&gt; применяет её давно и плотно.<br><br>напоминаю, первые выдернутые из моей памяти примеры: virtualbox, oracle (представим, что оракл вдруг осенился великой благодатью и лично кому-то из ваших майнтейнеров отдал схему сборки). <br>Применяя то и другое давно и плотно, ты по прежнему очень плохо будешь представлять себе, как оно устроено внутри. И если с первым еще при желании (а откуда оно возьмется?) разберешься (хотя правильней для дистрибутива потратить это время на разборки с его http-интерфейсом, кластеризацией и 3d-party мордами, чтобы это все уинтегрировать правильно - пользователи оценят), то второе - полный тупик, не бывает т https://slinkov.ru/openforum/vsluhforumID3/110879.html#170 Mon, 10 Apr 2017 07:38:12 GMT &gt; Если выбирать аналог Си, то я бы взял Паскаль.<br><br>Так Go же изобрели. Паскаль с Дельфями и FPC - прошлый век уже.<br>