Pull to refresh

Comments 25

Даа, грустно! Ведь mbedOS вроде как юзает asan clang'овский, на гитхабе хостятся и всякие другие модные слова употребляют. И на С++ пишут, а не на С.
Но нет, все равно malloc, а не new хотя бы, никаких умных контейнеров, и опять memset вместо std::fill. Фу.

Единственное, что из статьи не ясно — в чем же именно заключается поддержка GNU Arm Embedded? Я несколько лет назад проверял, что PVS-Studio сходу умеет работать с arm gcc — в конце концов, это ведь просто gcc.
Видимо, теперь учитывается какая-то специфика, но как раз про это в статье не написано.
В ядре у них полно C, так что насчет malloc ничего удивительного.

А насчет поддержки, фронтенд там целиком от gcc, так что в этом плане практически без изменений. Мы теперь правильно отличаем обычный gcc от того, который для ARM, и учитываем некоторые специфичные для платформы вещи. Плюс мы теперь под всеми системами автоматически его находим и правильно проставляем все настройки для анализа.
В ядре у них полно C, так что насчет malloc ничего удивительного.

Непонятно только зачем у них там С вообще. Но это к ним вопрос, не к вам :)

учитываем некоторые специфичные для платформы вещи

А вот тут хотелось бы поподробнее!
Если не ошибаюсь MBED базируется на RTX
Даже не базируется. Само ядро MBED — это такая C++ прослойка, в которую обёрнута старая сишная Keil RTX.
1) А планируется ли поддержка bare metal или других операционных сред?
2) Выработаны ли диагностики гонки, связанные с моделью памяти на ARM, которая существенно отличается от x86?
1) А планируется ли поддержка bare metal или других операционных сред?
Embedded — очень широкое направление. В приоритете пока поддержка чего-нибудь максимально популярного среди разработчиков и где работа препроцессора не сильно отличается от поддерживаемых нами компиляторов.
2) Выработаны ли диагностики гонки, связанные с моделью памяти на ARM, которая существенно отличается от x86?
Эта задача полноценно не решается статическим анализом, поэтому ничего нового мы не делали. А существующих диагностик на эту тему совсем не много.

Можно было бы проверить FreeRTOS как одну из самых распространенных открытые ОСРВ для встроенки.
я так понимаю кроссплатформенная версия имеет уже проприетарную лицензию и стоит денюжек?
Читать надо. Вполне возможно, что на использование не для встраивания можно и как-то договориться.
На моей памяти vxWorks всю жизнь была жестоко закрыта. Или я отстал от жизни?
ага, или ещё код сгенерированный с помощью CubeMX
UFO just landed and posted this here
Если вспоминать за «сгорит» — было бы любопытно прогнать PVS по ACE/TAO. Особенно по тому, что выдает их IDL компилятор.
Линаровский пока не делали, но там тоже gcc, так что в целом должно работать, только под Linux и macOS придется вручную указывать имена исполняемых файлов компиляторов.
Здесь следовало бы либо вызвать delete, либо хотя бы отдать хранящийся в переменной interface адрес наружу в любом случае, чтобы об этом мог позаботиться вызывающий код

а ещё лучше — std::unique_ptr::release
И, да, ребята, категорически умоляю, прячьте объяснения под кат, а то совсем неинтересно становится читать
Здравствуйте, можете по подробнее рассказать про связку PVS-Studio и Keil Embedded Development. Каким образом происходит взаимодействие: имеется некая интеграция в среду разработки или через внешний скрипт?
Добрый день.

Для проверки Keil-проектов у нас пока нет интеграции в среды разработки (uVision/Eclipse), поэтому анализ возможен только с помощью прямой интеграции в скрипты сборки или с использованием режимов мониторинга сборки (для Windows и Linux).

Вы можете запросить на сайте временный ключ для проверки своего проекта. Задать вопросы вы можете через форму обратной связи, или обменяться почтой через ЛС Хабра для продолжения общения.
Было бы интересно посмотреть на результат проверки RiotOS.
Присылайте проект в наш Check List на GitHub, откуда мы берём проекты для анализа.
О, за чеклист отдельное спасибо.
Sign up to leave a comment.