C *

Все мы любим делать вещи правильно. В интернете можно найти много статей с названием вроде «10 антипаттернов <...>», и, когда я пришёл на свою первую работу разработчиком, я думал, что из этих статей понял, как делать правильно, а как нет. К сожалению, реальность не всегда делится на плохое и хорошее, и некоторые вещи, которые встречаются в подобных статьях, всё-таки могут принести большую пользу при разработке.

Рассказываю о том, как сделать отчет о покрытии кода

Gcov — свободно распространяемая утилита для исследования покрытия кода. Gcov генерирует точное количество исполнений для каждого оператора в программе и позволяет добавить аннотации к исходному коду. Gcov поставляется как стандартная утилита в составе пакета GCC.

Lcov — графический интерфейс для gcov. Он собирает файлы gcov для нескольких файлов с исходниками и создает комплект HTML-страниц с кодом и сведениями о покрытии. Также генерируются страницы для упрощения навигации. Lcov поддерживает покрытие строк, функций, ветвлений.^[6]

В программировании микроконтроллеров приходится определять порядок инициализации прошивки. Порядок тут всегда имеет значение.

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

Чтобы всё это работало надо соблюдать правильный порядок инициализации.

В этом тексте я представил формальный алгоритм определения этого порядка.

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

Представляю вашему вниманию перевод работы A guide to inter-process communication in Linux. Объём данной работы большой, поэтому перевод будет выполнен в виде нескольких отдельных статей:

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

Ещё одна причуда Python, исследование её подноготной и попытка понять, почему так случается.

Недавно в сети X был популярен этот твит (см. скриншот), и я обратил внимание. Это очередной сюрприз в Python, связанный с характерными для него уникальными деталями реализации.

Если спросить программиста, какие баги чаще всего можно встретить в C и C++ коде, он назовёт разыменование нулевого указателя, неопределённое поведение, выход за границу массива и другие, на его взгляд, типовые паттерны ошибок. Скорее всего, он назовёт и случайное присваивание в условии. Но действительно ли эта ошибка распространена в наше время?

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

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

Основная идея - массив наша основная скрепа.

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

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

В программировании микроконтроллеров на Си часто приходится писать драйверы для умных и навороченных ASIC чипов с управлением по I2C/SPI/MDIO интерфейсам.

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

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

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

В данной статье я рассмотрю подключение утилиты dfu‑util, написанную на языке С, к С++ проекту на CMake в виде сабмодуля.

Одна из главных целей статьи — это подключение старого и типового кода на С к своему проекту. Здесь приведены проблемы генерируемых файлов, борьба с кодом незнакомого разработчика (особенно если это разработчик на Си), особенности портирования окружения на Windows и т. д.

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

* Превью сгенерировано с помощью Adobe Firefly

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

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

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

Мы продолжаем тему о проектировании и разработке вредоносного ПО для macOS. Первую часть публикации вы можете прочитать здесь. 

В этой статье мы:

- Изучим методики инъецирования кода и то, как он применяется в вредоносном ПО;

- Затронем способы обеспечения постоянства хранения;

- В конце мы покажем простой процесс инъецирования шелл-кода и его постоянного хранения. 

В этой статье мы погрузимся в мир проектирования и разработки вредоносного ПО для macOS, которая по сути является операционной системой на основе Unix. При исследовании внутренностей системы Apple мы воспользуемся классическим подходом с опорой на базовые знания эксплойтов, программирования на C и Python, а также знакомство с низкоуровневым языком ассемблера. Хотя представленные в статье темы могут быть сложными, я постараюсь изложить их понятным языком.

ReactOS — это проект, где победу над регрессией, появление новой фичи или её рабочего прототипа празднуют так громко, что FOSS‑сообществу приходится отвлекаться от переписывания всего на Rust и полемик о systemd. В последний раз мы проверяли ReactOS в 2013 году, почти одиннадцать лет назад. Проверка была неточной ввиду неполного понимания структуры папок, из‑за чего в поле видимости PVS‑Studio оставались компоненты Wine. Пришло время освежить память и провести новую проверку, учитывая опыт предыдущей недоработки.

Так или иначе сталкиваться с регулярными выражениями приходилось большинству разработчиков. Мое первое знакомство произошло с реализацией regex в STL std::regexp. Чаще всего регулярки используются в проверке входных данных, что-то вроде проверки корректности введенного пользователем URL, адреса IPv4, адреса IPv6, телефонного номера и при этом скорость выполнения операции regex не сильно влияет на время отклика от приложения. Но, что если вам приходится проверять сотни, тысячи или даже десятки тысяч правил и все это на постоянно меняющихся наборах входных данных в реальном времени? В этой ситуации вам не просто нужен быстрый алгоритм, вам понадобится лучший из них, вам понадобиться чемпион!

IBM i (AS/400) является "объектной" системой, построенной на концепции "все есть объект". У каждого объекта есть имя (может меняться в течении его жизненного цикла), тип (устанавливается единожды при создании и далее не меняется) и, в некоторых случаях, атрибуты ("подтип", аналогично типу, устанавливаются при создании и не могут быть изменены). Также объект может иметь текстовое описание (необязательное) - строка до 50-ти символов, которое может быть задано как при создании, так и после.

Действия, разрешенные над данным конкретным объектом, определяются его типом. Простейший пример - тут нельзя открыть программу в hex редакторе и поправить пару байтиков - такая операция просто не предусмотрена для объекта типа *PGM.

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

Цитата из предисловия к книге Френка Солтиса "Основы AS/400":

Приветствуем!

Так получилось, что нам достались два аттенюатора Agilent 8494H и 8496H. Они долго лежали без дела, поскольку отсутствовал контроллер управления. Конечно, четыре простых переключателя справились бы с этой задачей, но хотелось реализации с дисплеем показывающий текущее значение затухания и программное управление. Проект сделан в EasyEDA и Atmel Studio.