Я продолжаю обзор кода музыкальных приложений, и перед нами первый представитель коммерческого программного обеспечения. В комментариях к предыдущим статьям я заметил популярность программы Cubase и решил почитать о ней. Это продукт компании Steinberg, у которой есть несколько программ с закрытым исходным кодом. Случайно на их сайте я нашёл SDK для сторонних разработчиков, и, изучив его, обнаружил множество интересных ошибок.
Читать полностью »
Ardour пока является самым крупным из музыкальных проектов, участвующих в обзоре дефектов кода. Проект включает около 1000 файлов исходного кода на языке C++. Проект активно поддерживается сообществом разработчиков, при этом я не нашёл упоминаний об использовании каких-либо инструментов статического анализа. Как следствие — множество ошибок разного характера. В статье будут описаны самые интересные из них.
Читать полностью »
А давайте притащим мир большого программирования в Arduino!
Любая программа, а тем более программа близкая к аппаратуре (а какие еще на arduino бывают?) при рассмотрении представляет собой множество параллельно работающих ветвей.
При этом в реальной жизни обработка большинства вещей в реальном времени не требуется. Достаточно иметь нечто похожее на реальное время.
Например если мы программируем скажем гистерезисный регулятор температуры, то как правило совершенно не важно прямо сейчас сработает включатель нагревателя или через пару милисекунд.
А вот если мы программируем скажем регулятор ШИМ (не рассматриваем аппаратные способы), то тут нам возможно потребуется считать каждый такт процессора, чтобы обеспечить приемлемую точность регулирования.
Если рассмотреть структуру произвольного сложного программно-аппаратного проекта в том числе на Arduino, то увидим, что задач требующих "реального" (с жесткими требованиями) реалтайма — меньшинство, а большинству задач достаточно условного реалтайма.
Программирование реального реалтайма — это как правило прерывания и аппаратные хитрости. В этой статье поговорим о программировании реалтайма условного.
Добрый вечер, хаброчитатели!
В предыдущих статьях (один, два) мы определили понятие символьного устройства и написали простейший пример символьного драйвера. Последняя часть посвещена проверки его работоспособности. На Хабре уже есть примеры как можно протестировать драйвер, например: тык.
Я попытаюсь рассмотреть данный вопрос чуть подробнее, надеюсь, вам понравится.
Научное сообщество практически незнакомо со статическим анализатором кода PVS-Studio. 30 ноября и 1 декабря состоится мероприятие «Технологии анализа, моделирования и трансформации программ» в рамках открытой конференции ИСП РАН им. В.П. Иванникова. Я уверен, что это одно из самых тематичных для нас мероприятий, где новая аудитория могла бы узнать о существовании и возможностях анализатора PVS-Studio. На мой взгляд, наиболее подходящим для этого мог стать доклад, касающийся поиска ошибок в операционной системе Tizen. К сожалению, доклад получил отрицательные отзывы рецензентов и не будет включен в программу конференции. Тем не менее, пользуясь случаем, подведу итоги наших исследований, касающихся кода Tizen.
В этой статье я покажу, как написать рудиментарный, нативный x86-64 just-in-time компилятор (JIT) на CPython, используя только встроенные модули.
Код предназначен для UNIX-систем, таких как macOS и Linux, но его должно быть легко транслировать на другие системы, типа Windows. Весь код опубликован на github.com/cslarsen/minijit.
Цель — сгенерировать в рантайме новые версии нижеприведённого ассемблерного кода и выполнить их.
48 b8 ed ef be ad de movabs $0xdeadbeefed, %rax
00 00 00
48 0f af c7 imul %rdi,%rax
c3 retq
В основном, мы будем иметь дело с левой частью кода — байтовой последовательностью 48 b8 ed ... и так далее. Эти 15 байтов в машинном коде составляют функцию x86-64, которая умножает свой аргумент на константу 0xdeadbeefed. На этапе JIT будут созданы функции с разными такими константами. Такая надуманная форма специализации должна продемонстрировать базовую механику JIT-компиляции.
Читать полностью »
Мои читатели попросили сравнить проекты Manticore и Sphinx с точки зрения качества кода. Я могу сделать это только одним освоенным мною способом — проверить проекты с помощью статического анализатора PVS-Studio и посчитать плотность ошибок в коде. Итак, я проверил C и C++ код в этих проектах и, на мой взгляд, качество кода Manticore выше, чем качество кода Sphinx. Естественно, это очень узкий взгляд, и я не претендую на достоверность своего исследования. Однако меня попросили, и я сделал сравнение так, как умею.
Читать полностью »
Некоторое время назад, примерно с 2008 года, у меня был хобби-проект по воссозданию довольно знаменитого конце ХХ века ситибилдера Caesar III ©, в процессе работы над игрой был написан ряд статей по механике игры и её внутреннему устройству (например эта).
Какую вы знаете самую простую команду Unix? Есть echo, которая печатает строку в stdout, и есть true, которая ничего не делает, а только завершается с нулевым кодом.
Среди множества простых Unix-команд спряталась команда yes. Если запустить её без аргументов, то вы получите бесконечный поток символов "y", каждый с новой строки:
y
y
y
y
(...ну вы поняли мысль)Хотя на первый взгляд команда кажется бессмысленной, но иногда она бывает полезной:
yes | sh boring_installation.sh
Когда-нибудь устанавливали программу, которая требует ввести "y" и нажать Enter для установки? Команда yes приходит на помощь! Она аккуратно выполнит эту задачу, так что можете не отвлекаться от просмотра Pootie Tang.
Читать полностью »
Я хочу предложить вашему вниманию свежую статью «Undefined Behavior in 2017». Статья в оригинале имеет очень большой объём, и я разбил её на части.
В первой части речь пойдёт о разных инструментах поиска UB: ASan, UBSan, TSan и т.д.
ASan — Address Sanitizer от компании Google, разработанный на основе LLVM.
UBSan — Undefined Behavior Sanitizer, предназначен для обнаружения различных UB в программах на C и C++, доступен для Clang и GCC.
TSan — Thread Sanitizer, предназначен для обнаружения UB в многопоточных программах.
Если вам эта тема покажется далёкой от практики, я рекомендую дождаться продолжения, потому что в конце вас ждёт поистине огромный список UB языка С++ (их должно быть около 200!)
И я рекомендую прочитать также старые статьи Реджера, они не утратили актуальности.
Об авторе: Джон Реджер является профессором Computer Science в университете штата Юта в США.
Мы часто слышим, что некоторые люди утверждают, что проблемы, вытекающие из неопределённого поведения (UB) в C и C++ в основном решены путём широкого распространения инструментов динамической проверки, таких, как ASan, UBSan, MSan и TSan. Мы здесь покажем очевидное: несмотря на то, что в последние годы произошло множество прекрасных улучшений в этих инструментах, проблемы UB далеки от разрешения, и рассмотрим ситуацию в деталях.
