Тизен: Подводим Итоги

Наша команда написала три заметки, связанные с анализом кода операционной системы Tizen. Операционная система содержит много кода и поэтому является благодатной почвой для написания различных статей.

Думаю, что мы вернёмся к Tizen в будущем, но сейчас нас ждут другие интересные проекты.

Поэтому подведу некоторые итоги проделанной работы и отвечу на ряд вопросов, возникших после опубликованных ранее статей.

Работа выполнена

1. Андрей Карпов.

   27 000 ошибок в операционной системе Tizen .

   Фундаментальная статья, демонстрирующая важность использования статического анализа в крупных проектах.

   Статический анализатор PVS-Studio прекрасно продемонстрировал, сколько различных шаблонов ошибок он может обнаружить в коде на C/C++.

2. Андрей Карпов.

   Давайте поговорим о микрооптимизациях на примере кода Tizen. .

   На примере Tizen продемонстрируем, какие микрооптимизации кода предлагает анализатор PVS-Studio. Редактировать старый код нет необходимости, но обязательно стоит разработать новый код с учетом этих рекомендаций.

3. Сергей Хренов.

   Продолжаем изучать Tizen: компоненты C# оказались качественными .

   Но здесь анализатор PVS-Studio себя проявить не смог.

   Отказ.

   Но эта статья показывает, что мы честны в наших исследованиях.

   Нам удалось найти много интересных ошибок в коде C и C++ — мы об этом писали.

   Ошибок в C#-коде нам найти не удалось — об этом мы тоже писали.

Также появилось несколько новостных сообщений.

Базовый:

• Хорошие новости: Tizen от Samsung больше не является худшим кодом.

  Плохая новость: это все еще довольно ужасно.

• Исследователь утверждает, что ОС Tizen от Samsung плохо запрограммирована; Содержит 27 000 ошибок!

Нам нужно переписать всё на Rust

Этих энтузиастов отметили и в комментариях к нашим статьям.

Их предложение: чтобы избежать подобных ошибок, нам нужно всё переписать на Rust.



На самом деле мне все равно, переписано что-то или нет. В мире так много кода, написанного на C и C++, что еще через 50 лет анализатору PVS-Studio будет что проверять.

Если для Кобола до сих пор используются статические анализаторы, то для Си и Си++ они также потребуются еще многие десятилетия.

И все же, я не могу обойти эту тему стороной.

Вы серьезно предлагаете переписывать такие проекты на Rust? Как насчет того, чтобы взять и переписать 72 кода MLOC в Rust? Да, это безумие! Это потребует невероятного количества времени и усилий.

Более того, потратив много лет на разработку, вы в итоге получите ровно то же самое, что уже существовало! Было бы гораздо лучше вложить эти человеко-годы в создание чего-то нового на основе существующего проекта.

Кто-то возразит, что после такого переписывания код станет лучше и надежнее.

Такой гарантии вообще нет. В больших проектах значение языка не так велико.

Кроме того, многие библиотеки на языке C или C++ уже давно отлажены, и при переписывании придется изобретать велосипед, который долгие годы будет радовать пользователей разнообразными ошибками.

Я считаю, что тот, кто предлагает переписать 72 кода MLOC, просто некомпетентен.

Новичку это можно простить, но если это говорит человек со стажем, то он видимо тролль.

3,3% — это очень маленькая выборка, и ваша оценка частоты ошибок неверна.

Но об этом имеет смысл беспокоиться, если мы проверили 1000, 3000 или 10 000 строк кода.

Также стоит волноваться, если тестировался только один проект, написанный одной командой.

В другом проекте плотность ошибок может быть совсем другой.

Но напомню, что я (с помощью анализатора PVS-Studio) проверил 2 400 000 строк кода на C/C++.

Это много! Это размер некоторых проектов.

При этом проверялся код разных проектов.

Я использовал метод выборки «палец в небе».

Очень хороший и честный способ.

Вот список проектов, которые я изучал:

alsa-lib-1.0.28, aspell-0.60.6.1, augeas-1.3.0, привязка-9.11.0, efl-1.16.0, просветление-0.20.0, ise-engine-anthy-1.0.9, bluetooth- frwk-0.2.157, capi-appfw-application-0.5.5, capi-base-utils-3.0.0, capi-content-media-content-0.3.10, capi-maps-service-0.6.12, capi- media-audio-io-0.3.70, capi-media-codec-0.5.3, capi-media-image-util-0.1.15, capi-media-player-0.3.58, capi-media-screen-mirroring- 0.1.78, capi-media-streamrecorder-0.0.10, capi-media-vision-0.3.24, capi-network-bluetooth-0.3.4, capi-network-http-0.0.23, cynara-0.14.10, e-mod-tizen-devicemgr-0.1.69, ise-engine-default-1.0.7, ise-engine-sunpinyin-1.0.10, ise-engine-tables-1.0.10, isf-3.0.186, org. tizen.app-selector-0.1.61, org.tizen.apps-0.3.1, org.tizen.bluetooth-0.1.2, org.tizen.browser-3.2.0, org.tizen.browser-profile_common-1.6. 4, org.tizen.classic-watch-0.0.1, org.tizen.d2d-conv-setting-profile_mobile-1.0, org.tizen.d2d-conv-setting-profile_wearable-1.0, org.tizen.download-manager- 0.3.21, org.tizen.download-manager-0.3.22, org.tizen.dpm-toolkit-0.1, org.tizen.elm-demo-tizen-common-0.1, org.tizen.indicator-0.2.53, org.tizen.inputdelegator-0.1.170518, org.tizen.menu-screen-1.2.5, org.tizen.myplace-1.0.1, org.tizen.privacy-setting-profile_mobile-1.0.0, org.tizen. настройка конфиденциальности-profile_wearable-1.0.0, org.tizen.quickpanel-0.8.0, org.tizen.screen-reader-0.0.8, org.tizen.service-plugin-sample-0.1.6, org.tizen. настройка-1.0.1, org.tizen.settings-0.2, org.tizen.settings-adid-0.0.1, org.tizen.telephony-syspopup-0.1.6, org.tizen.voice-control-panel-0.1. 1, org.tizen.voice-setting-0.0.1, org.tizen.volume-0.1.149, org.tizen.w-home-0.1.0, org.tizen.w-wifi-1.0.229, org.tizen.w-home-0.1.0, org.tizen.w-wifi-1.0.229, орг.

tizen.watch-setting-0.0.1, менеджер безопасности-1.2.17.

Очевидно, что здесь работали разные команды специалистов.

Поэтому можно предположить, что полученное значение плотности обнаруженных ошибок является средним по остальному проекту.

Это не так плохо, как вы утверждаете

Например, можно было встретить такие безграмотные заголовки: «В коде операционной системы Tizen обнаружено 27 000 уязвимостей».

Это, конечно, неправда.

Позвольте мне объяснить, почему.

Скажу сразу, я писал не об уязвимостях, а об ошибках.

И ещё, в статье я ни разу не сказал, что Tizen — это некачественный код. Да, я говорю, что анализатор PVS-Studio выявляет много ошибок, но в любом большом проекте ошибок будет много.

Поэтому общее количество ошибок не говорит о качестве кода.

Давайте теперь поговорим немного подробнее об уязвимостях.

Среди всех ошибок, возникающих в программах, выделяются слабые места безопасности.

Их особенность в том, что может возникнуть стечение обстоятельств, когда данная ошибка может быть использована злоумышленником.

Эти типы ошибок описаны в К.

В.

Е.

.

CWE — это составленный сообществом список распространенных недостатков безопасности программного обеспечения.

В своей статье я классифицирую многие ошибки по классификации CWE. Однако это еще ничего не значит. Дело в том, что такие ошибки очень редко можно использовать в качестве уязвимостей.

Другими словами, очень редко CWE превращается в CVE. Подробнее о терминологии можно прочитать Здесь .

Еще раз подчеркну, что использовать ошибку в качестве уязвимости очень и очень редко.

В подавляющем большинстве случаев ошибка — это просто ошибка, которая хоть и неприятна для пользователей программы, но не вызывает проблем с безопасностью.

27 000 ошибок указывают на хорошее или плохое качество кода? Это невозможно сказать.

Однако это не такая страшная цифра, как может показаться на первый взгляд. Следует учитывать, что общий объем кода составляет 72 500 000 строк на C, C++ (без учета комментариев).

Получается, что анализатор PVS-Studio обнаруживает примерно 0,37 ошибок на 1000 строк кода.

Или другими словами примерно 1 ошибка на 3000 строк кода.

Примечание.

Не следует путать это с общим количеством ошибок в коде Tizen. Это то, что мы можем определить, а не то, сколько их.

Пожалуйста, обратите на это внимание, так как некоторые люди неправильно интерпретируют данные.

Так, PVS-Studio обнаруживает примерно 0,37 ошибок на 1000 строк кода.

Это много или мало? Скорее средний.

Это может быть лучше и хуже.

Вот некоторые примеры:

• Блокнот++: мы нашли около 2 ошибок на 1000 строк кода.

• Far Manager для Linux: мы мы нашли около 0,46 ошибок на 1000 строк кода.

• Проект Tor: мы вообще никто мы не находим .

  Плотность 0.

На самом деле никакой сенсации нет. Количество ошибок в 27 000 шокирует, но такое впечатляющее количество обусловлено большим размером проекта Tizen. Если взять еще один крупный проект, там тоже будет много ошибок.

Целью моей статьи было показать, что инструмент PVS-Studio может быть полезен для проекта Tizen. И кажется, мне это удалось.

Однако я совершенно не ожидал той бурной реакции и дискуссии, которая возникла вокруг этой статьи.

Подобные заметки мы пишем регулярно.

С ними вы сможете читай здесь .

В статье не указан процент ложных срабатываний

К сожалению, многие читатели читают статьи очень невнимательно.

В результате они довольно часто неправильно воспринимают цифры, которые в них указаны.

Я уже хорошо знаком с этим эффектом и стараюсь учитывать его в своих статьях.

Например, в статье про «27 000 ошибок» я специально дважды написал, что нашел 900 ошибок, исследовав 3,3% кода.

При этом он подчеркнул, что речь идет именно об ошибках, а не о количестве предупреждений, выдаваемых анализатором.

И хотя я перестраховался, этот комментарий все же появился: 900 предупреждений в аналоге Линта не означают 900 ошибок.

Я бы даже сказал, что эти показатели вообще не связаны между собой.

Наверняка были ошибки в форматировании кода, области видимости переменных и т. д. В топку таких аналитиков.

Человек не читал статью, но увидел цифру 900 и спешит поделиться своим мнением с другими.

Именно по этой причине я не пишу о количестве ложных срабатываний.

Люди увидят определенное число, а потом много лет будут везде писать в комментариях «это плохой анализатор, у которого процент ложных срабатываний NN».

Дело в том, что анализатор требует настройки.

При этом большинство ложных срабатываний связано с небольшим количеством макросов.

Я неоднократно демонстрировал в некоторых своих статьях, как подавление предупреждений для нескольких макросов резко снижает количество ложных срабатываний.

То же самое и с Тизеном.

Однако боюсь, что на эти объяснения и примеры мало кто обратит внимание.

Но цифру, означающую большой процент ложных срабатываний, запомнит каждый.

Возникает логичный вопрос: Тогда почему бы вам не поставить статический анализатор и сразу не показать хороший результат? Я отвечаю.

Это займет время, а меня еще ждут такие интересные проекты, как iOS или Android. Однако это не главная причина, почему я не хочу этого делать.

Дело в том, что непонятно, где остановиться.

Я знаю, что приложив некоторые усилия, мы можем снизить количество ложных срабатываний до нуля или почти до нуля.

Например, мы сократили количество ложных срабатываний до нуля, когда работали над проектом Unreal Engine (см.

статьи 1 , 2 ).

Итак, если я использую настройки, чтобы снизить количество ложных срабатываний до какого-то очень маленького процента, мне скажут, что это нечестно.

Получается, что с одной стороны мне захочется оставить как можно меньше ложных срабатываний, с другой стороны нельзя переусердствовать, показывая слишком идеальный вариант. Как-то мне все это не нравится.

Я считаю, что лучше вообще ничего не делать.

Так как же программисту понять, хорошо или плохо работает наш анализатор? Очень просто! Нужно это скачать и попробуйте проверить рабочий проект. Сразу станет понятно, нравится он вам или нет. И сразу будет понятно, сколько ложных срабатываний и какого они типа.

После чего, возможно, ваша компания будет рада пополнению список наших клиентов .

Я просто прошу вас не совершать ошибку, пробуя анализатор на небольших проектах или тестовых примерах в целом.

Причины:

• Чувства, подтверждённые цифрами (в небольших проектах низкая плотность ошибок).

• Почему я не люблю синтетические тесты (тесты не отражают реальные типы ошибок).

Добавляю это примечание после написания статьи.

Ладно, читатели победили.

Я сдаюсь и даю номер.

Я провел исследование EFL Core Libraries и подсчитал, что статический анализатор PVS-Studio будет выдавать около 10-15% ложных срабатываний.

Вот статья об этом: Характеристики анализатора PVS-Studio на примере EFL Core Libraries .

Хватит -Стена -Вестра -Werror

Необходимы дополнительные инструменты.

Статические анализаторы — это специализированные инструменты, которые по своим диагностическим возможностям всегда опережают компиляторы.

За это они получают деньги от своих клиентов.

Однако помимо слов у меня есть и доказательства.

Каждый раз, когда мы проверяем компилятор, мы находим там ошибки:

• Проверка LLVM (Clang) (август 2011 г.

  ), вторая проверка (август 2012 г.

  ), третья проверка (октябрь 2016 г.

  )

• Проверка GCC (август 2016 г.

  )

• В случае с Visual C++ мы проверяли системные библиотеки.

  Раз мы находим там ошибки, значит Visual C++ их не видит. Проверка библиотек Visual C++ (сентябрь 2012 г.

  ), вторая проверка (октябрь 2014 г.

  ), третья проверка (май 2017 г.

  ).

Вот некоторые возможности PVS-Studio:

• Удобная и простая интеграция с Visual Studio 2010-2017.
• Интеграция с SonarQube.
• Утилита BlameNotifier. Инструмент позволяет отправлять письма разработчикам об ошибках, обнаруженных PVS-Studio во время ночной работы.

• Массовое подавление – позволяет подавить все старые сообщения, чтобы анализатор генерировал 0 тревог.

  Вы всегда можете вернуться к скрытым сообщениям позже.

  Возможность безболезненно внедрить PVS-Studio в существующий процесс разработки и сосредоточиться на ошибках только в новом коде.

• Сохранение и загрузка результатов анализа: можно проверить код ночью, сохранить результаты, а утром загрузить и посмотреть.

• Поддержка IncrediBuild.
• Mark as False Alarm - пометка в коде, чтобы не ругаться на конкретную диагностику в конкретном фрагменте файла.

• Интерактивная фильтрация результатов анализа (журнала) в окне PVS-Studio: по диагностическому коду, по имени файла, по включению слова в текст диагностики.

• Статистика ошибок в Excel — можно увидеть скорость исправления ошибок, количество ошибок с течением времени и т. д.
• Автоматическая проверка наличия новых версий PVS-Studio (как при работе в IDE, так и при ночных сборках).

• Использование относительных путей в файлах отчетов для возможности передачи отчета на другой компьютер.

• CLMonitoring — проверка проектов, не имеющих файлов Visual Studio (.

  sln/.

  vcxproj); если вдруг вам не хватит функционала CLMonitoring, то вы можете интегрировать PVS-Studio в любую систему сборки на основе Makefile вручную.

• pvs-studio-analyzer — утилита, похожая на CLMonitoring, но работающая под Linux.
• Возможность исключать файлы из анализа по имени, папке или маске.

Нет цены

Это стандартная практика для компаний, продающих решения для статического анализа кода.

Мы позиционируем PVS-Studio как B2B-решение.

При продаже компаниям приходится согласовывать множество моментов, влияющих на цену лицензии.

Размещать конкретную цену на сайте нет смысла, продуктивнее сразу начать обсуждение.

Почему мы не работаем с индивидуальными застройщиками? Мы пытались, но у нас не получилось .

Однако отдельные разработчики могут использовать один из вариантов бесплатной лицензии:

• Для этого они должны согласиться с условием модификации кода: как использовать PVS-Studio бесплатно .

• Также мы свободны Предоставляем анализатор PVS-Studio специалистам по безопасности .

• Получить бесплатную версию может каждый Самый ценный игрок Майкрософт .

Не все области, которые вы упомянули в статье, являются реальными ошибками.

С другой стороны, тщательный анализ может обнаружить, что я, наоборот, упустил некоторые ошибки.

Например, мне было лень изучать предупреждения В730 — Не все члены класса инициализируются внутри конструктора.

Очень трудоемко пытаться понять в чужом коде, является ли ошибкой то, что какой-то член класса остался неинициализированным.

Однако, если вы сделаете это, вы, вероятно, обнаружите настоящие ошибки.

Давайте рассмотрим один из таких случаев.

Код принадлежит проекту org.tizen.browser-profile_common-1.6.4. Во-первых, давайте посмотрим на определение класса ЗакладкаЭлемент .

   

 class BookmarkItem
 {
 public:
     BookmarkItem();
     BookmarkItem(
         const std::string& url,
         const std::string& title,
         const std::string& note,
         unsigned int dir = 0,
         unsigned int id = 0
         );
     virtual ~BookmarkItem();
 
     void setAddress(const std::string & url) { m_url = url; };
     std::string getAddress() const { return m_url; };
 
     void setTitle(const std::string & title) { m_title = title; };
     std::string getTitle() const { return m_title; };
 
     void setNote(const std::string& note){m_note = note;};
     std::string getNote() const { return m_note;};
 
     void setId(int id) { m_saved_id = id; };
     unsigned int getId() const { return m_saved_id; };
 
     .


     .


 
     bool is_folder(void) const { return m_is_folder; }
     bool is_editable(void) const { return m_is_editable; }
 
     void set_folder_flag(bool flag) { m_is_folder = flag; }
     void set_editable_flag(bool flag) { m_is_editable = flag; }
 
 private:
     unsigned int m_saved_id;
     std::string m_url;
     std::string m_title;
     std::string m_note;
     std::shared_ptr<tizen_browser::tools::BrowserImage> m_thumbnail;
     std::shared_ptr<tizen_browser::tools::BrowserImage> m_favicon;
     unsigned int m_directory;
     std::vector<unsigned int> m_tags;
     bool m_is_folder;
     bool m_is_editable;
 };

   

Обратите внимание, что они находятся в конце описания класса.

Готов поспорить на 10 долларов, что изначально их не было в первой версии класса и они появились позже, в процессе разработки проекта.

Итак, когда эти члены были добавлены, был изменен только один конструктор.

В результате у нас есть два конструктора:

BookmarkItem::BookmarkItem() : m_saved_id(0) , m_url() , m_title() , m_note() , m_thumbnail(std::make_shared<.

>()) , m_favicon(std::make_shared<.

>()) , m_directory(0) , m_is_folder(false) , m_is_editable(true) { } BookmarkItem::BookmarkItem( const std::string& url, const std::string& title, const std::string& note, unsigned int dir, unsigned int id ) : m_saved_id(id) , m_url(url) , m_title(title) , m_note(note) , m_directory(dir) { }

Один конструктор инициализирует члены m_is_folder И m_is_editable , а другой нет. Я не совсем уверен, но это скорее всего ошибка.

Анализатор PVS-Studio для второго конструктора выдает следующее предупреждение: V730. Не все члены класса инициализируются внутри конструктора.

Рассмотрите возможность проверки: m_is_folder, m_is_editable. BookmarkItem.cpp 268 Кстати, анализатор PVS-Studio умеет искать 64-битные ошибки.

Tizen все еще 32-битный, поэтому для него они пока не актуальны, но я хочу посвятить этой теме несколько слов.

На самом деле никаких «64-битных ошибок» не существует. Однако некоторые ошибки имеет смысл отнести к этой категории и рассмотреть их отдельно.

Дело в том, что подобные ошибки никак не проявляются в 32-битной версии приложений.

Более того, они вообще не проявляются и не могут быть обнаружены никаким тестированием.

Давайте рассмотрим простой пример для пояснения.

Вам необходимо создать массив указателей и для этого написан следующий ошибочный код:

int **PtrArray = (int **)malloc(Count * size_of(int));

Память выделяется под массив интервал , а не для массива указателей.

Правильный код должен был быть:

int **PtrArray = (int **)malloc(Count * size_of(int *));

Ошибка в 32-битной программе себя не проявляет. Указатель и размер шрифта интервал совпадают, поэтому выделяется буфер правильного размера.

Все работает корректно и проблемы начнутся только тогда, когда мы начнем собирать 64-битную версию программы.

Примечание.

Конечно, в некоторых 64-битных системах размер указателя может совпадать с размером типа.

интервал .

Или может быть, что размеры будут другими в 32-битных системах.

Это экзотика, о которой нет смысла говорить.

Рассмотренный пример будет корректно работать на всех распространенных 32-битных системах и не работать на 64-битных.

На нашем сайте вы можете найти много интересных материалов, посвященных 64-битным ошибкам и способам их устранения:

1. Сборник примеров 64-битных ошибок в реальных программах.

2. C++11 и 64-битные ошибки
3. Неопределённое поведение ближе, чем вы думаете
4. Уроки разработки 64-битных приложений на C/C++

Анализатор PVS-Studio выдает 11 предупреждений с кодом В204 :

1. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   mv_testsuite_common.c 94

2. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   mv_video_helper.c 103

3. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   mv_video_helper.c 345

4. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   mv_mask_buffer.c 39

5. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   mv_surveillance.c 52

6. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   mv_surveillance.c 134

7. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   mv_surveillance.c 172

8. V204 Явное преобразование 32-битного целочисленного типа в тип указателя.

   наблюдение_test_suite.c 452

9. V204 Явное преобразование 32-битного целочисленного типа в тип указателя: (unsigned char *) malloc(buf_size) наблюдения_test_suite.c 668
10. V204 Явное преобразование 32-битного целочисленного типа в тип указателя: (unsigned char *) malloc(buf_size) наблюдения_test_suite.c 998
11. V204 Явное преобразование 32-битного целочисленного типа в тип указателя: (unsigned char *) malloc(buf_size) наблюдения_test_suite.c 1109

маллок .

Вы можете убедиться в этом, предварительно обработав файлы C и просмотрев их содержимое.

i-файлы .

Использование функции маллок есть, но рекламы по ней нет. Поскольку эта программа написана на языке C, она компилируется, несмотря на отсутствие объявления.

Поскольку функция не объявлена, считается, что она принимает и возвращает аргументы типа интервал .

Те.

Компилятор думает, что функция объявлена так:

int malloc(int x);

Благодаря этому 32-битная программа отлично компилируется и работает. Указатель помещается в тип интервал и все хорошо.

Эта программа также будет компилироваться в 64-битном режиме.

Это почти всегда работает. Что важно, так это «почти всегда».

Все будет хорошо, пока память распределяется по младшим адресам адресного пространства.

Однако во время работы память в нижней части адресного пространства может оказаться занятой или фрагментированной.

Затем диспетчер памяти вернет память, выделенную за пределами младших адресов.

Сбой произойдет из-за усечения старших битов указателя.

Я подробнее описал, как и что здесь происходит:" Красивая 64-битная ошибка на языке C ".

В результате мы видим 11 дефектов, которые могут привести к трудновоспроизводимым сбоям программы.

Очень неприятные ошибки.

К сожалению, диагностика PVS-Studio по обнаружению 64-битных ошибок генерирует много шума (ложных срабатываний) и с этим ничего не поделаешь.

Это их природа.

Анализатор часто не знает, каков диапазон тех или иных значений, и не может понять, что код будет работать корректно.

Но если вы хотите сделать надежное и быстрое 64-битное приложение, вам следует работать со всеми этими предупреждениями.

Кстати, мы можем взять на себя эту кропотливую работу и провести кастомное портирование приложения на 64-битную систему.

У нас есть опыт в этой области (см.

Как перенести проект из 9 миллионов строк кода на 64-битную платформу ").

Так что если разработчики Tizen захотят сделать систему 64-битной, то знайте, наша команда готова в этом помочь.

Заключение

Тем, кто заинтересовался анализатором PVS-Studio и хочет узнать больше о его возможностях, предлагаю посмотреть большую презентацию (47 минут): Статический анализатор кода PVS-Studio для C, C++ и C# .

Приглашаю вас подписаться, чтобы быть в курсе новых публикаций:

• Твиттер: @Code_Anaанализ
• РСС: viva64-блог-ру
• Линкедин: PVS-Студия
• Фейсбук: Статиккоданализатор

Тизен: подведение итогов Вы прочитали статью и у вас есть вопросы? Часто о наших статьях задают одни и те же вопросы.

Ответы на них мы собрали здесь: Ответы на вопросы читателей статей о PVS-Studio версии 2015 .

Пожалуйста, проверьте список.

Теги: #информационная безопасность #открытый исходный код #C++ #статический анализ кода #ревью кода #C/C++ #pvs-studio #ошибки в коде #результаты #tizen #Разработка для Tizen #cwe #tizen os #плотность ошибок

• Хотите Работать На Дому, Чтобы Зарабатывать Деньги?

  19 Oct, 24

• Будущее Программного Обеспечения Для Планирования Ресурсов Предприятия Для Организаций

  19 Oct, 24

• Как Наказать Провинившихся Сотрудников, Вопрос Второй: Onetwotrip, Notamedia И Другие

  19 Oct, 24

• Самые Перспективные Стартапы 2016 Года — Выбор Business Insider

  19 Oct, 24

• Будет Ли Достигнут Рубеж В 100 000 Долларов Сша? На Аукционе По Продаже Домена Am.ru?

  19 Oct, 24

• Инструмент Для Сравнения Css-Фреймворков

  19 Oct, 24

• Virtuozzo Storage: Реальный Опыт Эксплуатации, Советы По Оптимизации И Решению Проблем

  19 Oct, 24

• Civ 5 Сможет Импортировать Карты Из Civ 4.

  19 Oct, 24

• Новые Powermates

  19 Oct, 24

• Пынск №11 - Первая Встреча Новосибирских Питонистов В 2017 Году.

  19 Oct, 24