C *

В данной публикации представлена транскрипция вебинара «Всесторонний статический анализ с применением продуктов Polyspace». Вебинар проводил Михаил Песельник, инженер ЦИТМ Экспонента).

Цель всех процессов разработки и верификации ПО заключается в том, чтобы убедиться в том, что в финальном программном обеспечении больше нет дефектов. Почему так важно убедиться, что ПО является надежным? Давайте подумаем о последствиях и затратах, связанных с ошибками в программном обеспечении.

Многим известна проблема трёхмерной графики — отсутствие легковесных кроссплатформенных решений в вопросе вывода текста.

Большинство реализаций позволяет использовать выбранный шрифт в виде текстуры. Публикуемая библиотека ttf2mesh реализует другой способ — она преобразует векторные символы TrueType шрифта в сеточные объекты. Это позволяет выводить текст в виде набора треугольников.

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

В октябре 2019 года со мной случилась школа программирования 42, находящаяся во Фримонте, штат Калифорния. По возвращении из неё я упорно отказывалась отвечать на различные вопросы об учёбе и избегала делиться своими впечатлениями. Нужно было время прийти в себя. Более полугода спустя я готова рассказать свою историю о, возможно, самом необычном опыте в моей жизни.

От переводчика: предлагаю вашему вниманию перевод очень старой статьи, опубликованной 15 января 1983 года. Несмотря на столь внушительный возраст, статья показалась мне интересной, и возможно, что она будет полезной для кого-то и сегодня. На эту статью, кстати, ссылается раздел справки man locate(1) на opennet.ru: https://www.opennet.ru/man.shtml?topic=locate.

Краткое содержание

Статья описывает механизм быстрого поиска файлов в UNIX. Он объединяет два метода компрессии данных с новой техникой поиска строк, и предназначен для быстрого поиска произвольных файлов. Код, интегрированный в стандартную утилиту find, производит поиск в предварительно созданной базе данных, обновляемой ежедневно. Это отличает его от обычного механизма поиска совпадений ключа с кандидатами, которые генерируются «на лету» из разбросанной (по диску) структуры директорий.

База данных путей к файлам является инкрементально-кодированным, отсортированным в лексикографическом порядке списком (иногда называемом «сжатым спереди» файлом), который также подвергнут обычному биграмному кодированию с целью получения эффективного сжатия. Коэффициент сжатия составляет от 5 до 6 по сравнению с обычным ASCII-представлением. Список сканируется с использованием модифицированного линейного поиска, специально приспособленного для инкрементального кодирования, при этом типичное время, затрачиваемое алгоритмом, на 40-50% меньше, чем обычный поиск.

Только что вышла первая версия разработанного мной статически типизированного встраиваемого скриптового языка Umka. Он призван сочетать гибкость привычных скриптовых языков с защитой от ошибок типов на этапе компиляции в байт-код. Основная идея языка — Explicit is better than implicit — позаимствована из «дзена Python», однако должна приобрести здесь несколько иной и более очевидный смысл.

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

Хотя данная информация уже устарела, оригинальный материал и по сей день является популярным источником вдохновения для различного полезнейшего контента по теме FFmpeg. При этом полного перевода оригинала на русский язык до сих пор нет. Исправляем досадное упущение, ибо лучше поздно, чем никогда.

И хотя мы старались, в таком объёмном тексте неизбежны трудности перевода. Сообщайте о недочётах (желательно, в личных сообщениях) — вместе сделаем лучше.

Оглавление

Спойлер: C++ не быстрее и не медленнее и вообще смысл не в этом. Эта статья является продолжением славных традиций развенчания мифов крупных российских компаний о языке Rust. Предыдущая была "Go быстрее Rust, Mail.Ru Group сделала замеры".

Недавно я пытался заманить коллегу, сишника из соседнего отдела, на Тёмную сторону Rust. Но мой разговор с коллегой не задался. Потому что, цитата:

В 2019 году я был на конференции C++ CoreHard, слушал доклад Антона antoshkka Полухина о незаменимом C++. По словам Антона, Rust еще молодой, не очень быстрый и вообще не такой безопасный.

Антон Полухин является представителем России в ISO на международных заседаниях рабочей группы по стандартизации C++, автором нескольких принятых предложений к стандарту языка C++. Антон действительно крутой и авторитетный человек в вопросах по C++. Но доклад содержит несколько серьёзных фактических ошибок в отношении Rust. Давайте их разберём.

Embox – это кросс-платформенная мультизадачная операционная система реального времени для встраиваемых систем. Она рассчитана на работу в условиях невысоких вычислительных ресурсов и позволяет запускать Linux-приложения на микроконтроллерах без использования самого Linux. Конечно, как и любые другие приложения, Embox баги тоже не обошли стороной. Данная статья посвящена разбору ошибок, найденных в коде проекта Embox.

Материал статьи взят с моего дзен-канала.

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

Отладка крафтовых фильтров

После того, как мы в предыдущей статье рассмотрели механизм перемещения данных в медиастримере будет логично поговорить о скрывающихся в нем опасности. Одна из особенностей принципа "data flow" состоит в том, что выделение памяти из кучи происходит в фильтрах, которые находятся у истоков потока данных, а освобождение памяти с возвращением в кучу делают уже фильтры, расположенные в конце пути потока. Кроме этого, создание новых данных и их уничтожение может происходить где-то в промежуточных точках. В общем случае, освобождение памяти выполняет не тот фильтр, что создал блок данных.

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

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

Материал статьи взят с моего дзен-канала.

Механизм перемещения данных

• Блок данных dblk_t
• Сообщение mblk_t
• Функции работы с сообщениями mblk_t
• Очередь queue_t
• Функции работы с очередями queue_t
• Соединение фильтров
• Сигнальная точка графа обработки данных
• Закулисная деятельность тикера
• Буферизатор MSBufferizer
• Функции работы с MSBufferizer

В прошлой статье мы разработали свой собственный фильтр. Эту статью мы посветим устройству внутреннего механизма перемещения данных между фильтрами медиастримера. Это позволит в дальнейшем писать изощренные фильтры с меньшими усилиями.

В качестве входных данных выступает массив типа float. Программа организует отображение, растягивание, прокрутку графика.

Полгода назад мне захотелось создать лучший генератор псевдослучайных чисел (ГПСЧ) с какой-нибудь необычной архитектурой. Я думал, что начало будет лёгким, а по мере работы задача станет медленно усложняться. И думал, смогу ли я научиться всему достаточно быстро, чтобы справиться с самым сложным.

К моему удивлению, сложность возрастала не линейно. Побайтовое тестирование по критерию хи-квадрат оказалось очень трудным! Позднее столь же трудно было пройти тесты diehard. Я опубликовал текущие результаты, чтобы понять, какие ещё трудности меня ожидают. Однако тест PractRand в тот раз пройти не удалось.

Затем было очень трудно прохождение теста BigCrush.

Затем было очень трудно передавать 32 тебибайта данных при прохождении PractRand. Скорость стала проблемой. Мало было создать конструкцию, генерирующей десять мегабайтов в секунду, потому что прохождение PractRand заняло бы месяц. Но должен признаться, что пройти этот тест со скоростью гигабайт в секунду было очень трудно.

Недавно на просторах интернета мной был обнаружен физический движок Newton Game Dynamics. Зная, что в таких проектах обычно большой объём сложного кода, я подумал, что будет интересно проверить его статическим анализатором PVS-Studio. Мой энтузиазм ещё больше подстегнуло то, что мой коллега Андрей Карпов уже проверял данный проект в 2014 году, а значит, это ещё и хорошая возможность продемонстрировать развитие нашего анализатора за последние шесть лет. Также стоит отметить, что на момент написания статьи последний релиз Newton Game Dynamics датирован 27 февраля 2020 года, то есть данный проект тоже активно развивается последние 6 лет. Таким образом, надеюсь, что помимо нашей команды, данная статья будет интересна и разработчикам движка, которые смогут избавиться от некоторых багов и исправить свой код.

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

Смысл использования языка С при разработке расширений для PostgreSQL по сравнению с интерпретируемыми (скриптовыми) языками можно свести к двум положениям: производительность и функциональность. Ну а по простому, код написанный на С будет работать намного быстрее, например, если функция вызывается миллион раз в запросе на каждую запись. А более конкретно, некоторые возможности PostgreSQL и вовсе нельзя сделать кроме как на С, например, в других языках не поддерживаются типы (особенно если возвращать значение из функции) ANYELEMENT, ANYARRAY и особенно важный VARIADIC.

Материал статьи взят с моего дзен-канала.

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

Разрабатываем плагин

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

Чтобы использовать плагин в своей программе, вы с помощью include должны подключить заголовочный файл плагина. В теле программы, с помощью функции у ms_filter_register() выполнить регистрацию нового фильтра. Естественно, ваша программа и и исходник плагина должны быть скомпилированы и собраны в одно приложение.

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

После появления переводной статьи про Статический анализ в GCC 10, и ожидаемой реакции присутствующих здесь представителей разработчика коммерческого статического анализатора PVS-Studio, у меня возник вопрос: «Почему же представители отказываются проверить свой продукт на таких простых примерах для статического анализа, и не скрывают ли они чего?»

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

Должны же они как то прогонять юнит-тесты своего продукта и как, если не на таких синтетических простых примерах?!

Собственно, пришлось сделать это самому.

Компилятор GCC написан с обильным использованием макросов. Очередная проверка кода GCC с помощью PVS-Studio вновь подтверждает мнение нашей команды, что макросы – это плохо. В таком коде тяжело разбираться не только статическому анализатору, но и программисту. Конечно, разработчики GCC уже привыкли к проекту и хорошо разбираются в нём. Но со стороны очень сложно что-то понять. Собственно, из-за макросов и не удалось полноценно выполнить проверку кода. Тем не менее, анализатор PVS-Studio, как всегда, показал, что может находить ошибки даже в компиляторах.

Привет, Хабр!

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

1. Продукту CLion вчера исполнилось 5 лет! В честь праздника мы смонтировали небольшую видеоисторию, своеобразное воспоминание и рассказ о том, как же интересно все развивалось для нас эти 5 лет. Сразу предупредим, история на английском:
   
   
   
   
2. Вчера же случился первый в этом году большой релиз продукта – CLion 2020.1. В нем мы поддержали диалект CUDA, переписали Dataflow Analysis на Clang, научили IDE работать с компиляторами Clang-cl и IAR, а также внесли множество других улучшений и исправлений.
   
3. Последние несколько месяцев нашей команде стало очень грустно без конференций и сопутствующих выставок, где мы всегда с удовольствием находимся у стендов компании и много общаемся с нашими пользователями и сообществом в целом. Поэтому мы решили организовать онлайн-сессию вопросов и ответов с командой – CLion Ask Me Anything (AMA) session. Сессия пройдет 7 мая в режиме реального времени, требуется предварительная запись. Присоединяйтесь и задавайте любые вопросы по продукту!

Теперь давайте поговорим подробнее обо всех этих событиях.

В современных x86 процессорах Intel конвеер можно разделить на 2 части: Front End и Back End.

Front End отвечает за загрузку кода из памяти и его декодирование в микрооперации.

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

В большинстве случаев неэффективное использование Front End'a не оказывает заметного влияние на производительность. Пиковая пропускная способность на большинстве процессоров Intel — 4 микрооперации за такт, поэтому, например, для Memory/L3-bound кода ЦПУ не сможет полностью ее утилизировать.


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