C *

Мне часто задают такой вопрос: как мы пишем на C код для curl, чтобы он был безопасным и надёжным в миллиардах установок? Мы предпринимаем определённые меры и принимаем решения. «Серебряной пули» нет, есть только рекомендации. Как вы убедитесь сами из этой статьи, в них тоже нет ничего странного или неожиданного.

«c» в слове «curl» не обозначает и никогда не обозначало язык программирования C, это расшифровывается как client.

Предупреждение

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

Недавно МЦСТ опубликовала кросскомпилятор для «Эльбрус». Это большой шаг в развитии платформы. Теперь любой человек может собрать программу под е2к на своем домашнем компьютере.

В этой статье вас ждет инструкция по ручному развертыванию всего окружения для разработки под е2к, скрипт для автоматического развертывания, а также Docker-контейнер с готовым окружением. Благодаря контейнеру процесс развертывания упрощается до вызова одной команды, а также он позволяет работать даже на Windows.

Если вы хотели попробовать собрать свой код или какой-нибудь другой код под «Эльбрус», то сейчас самое время.

В биографии Эдуарда Лимонова — писателя, диссидента и политика — есть неожиданный эпизод: в конце 1970-х годов, во время жизни в США, он подрабатывал в IT-сфере и, по некоторым данным, участвовал в разработке ранних версий языка C.

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.

В этот раз поговорим про написание кода методом Copy-Paste. С одной стороны, программисты знают, что копирование кода с последующей его модификацией провоцирует ошибки и опечатки. С другой — набирать каждый раз фрагмент кода, похожий на уже написанный, скучно и непродуктивно. Здесь важно соблюдать некий баланс, который сложно сформулировать и понимание которого приходит с опытом.

Игра Rogue знаменита не только тем что породила и вдохновила огромное количество "потомков" - от визуально схожих Moria и NetHack до графически продвинутых вроде DIablo. Знаменита она ещё и тем что является одной из самых сложных игр для прохождения (в этом классе она гораздо интеллектуальнее чем Flappy Bird). Не уверен что вы найдете даже по форумам человека который скажет что проходил её (не читеря с файлами сохранения). А может такие есть среди вас?

Я заметил что современная опенсорсная версия (например доступная в пакетах для разных Linux и BSD) отличается от той, например, что была портирована коммерчески под ДОС где-то в 80е. Заметно отличаются монстры - чуть ли не со 2 уровня уже можно напороться на Ледяного Монстра который не только лишает подвижности но ещё и активно дамажит. Как будто и без того сложная игра стала ещё сложнее!

Дело в том что ранний код Rogue изначально не был доступен публично - кроме того авторы опенсорсной версии хотели избежать возможных нарушений прав (т.к. существовали уже коммерческие порты).

Чтобы разобраться я решил скомпилировать и запустить одну из самых старых доступных версий - посмотреть отличия - и вообще как что устроено. Здесь я расскажу о возникших мелких проблемах (любопытно м.б. для программистов на С) - и возможностях этой самой оживлённой версии (её я выложил на гитхаб - каждый может взять и погонять).

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

В этом HowTo мы рассмотрим подготовку пакетов vcpkg для использования в двоичном виде.

В качестве "подопытных кроликов" будут выступать Qt6, QCustomPlotи я.

Spoiler: с QCustomPlot придется немного пострадать, но обычно все проще.

TLDR: vcpkg export

Ведущий инженер-разработчик Postgres Professional Николай Шаплов столкнулся с неожиданной проблемой при тестировании: коллизии хэшей в clang ломали метрики покрытия. Расскажем, как удалось решить эту задачу и что это меняет для всего сообщества.

Шёл 2025 год, а я задался вопросом: «Не пора ли нашей команде выбрать стандарт языка Си, на котором будет вестись основная часть разработки?» С одной стороны кажется, что этот вопрос давно должен быть решён, стандарт языка указан в code style, конечно, после «холиваров», череды обсуждений, обид, проклятий и прочих маленьких трагедий. А если нет? А если нет, то так ли это важно? Что там нового может быть в языке Си? Стоит ли этот вопрос вообще того, чтобы тратить время? В этой заметке поделюсь с уважаемым читателем тем интересным, что я узнал и вспомнил во время неспешного исследования этого вопроса, относительно холодными и тёмными вечерами.

Первая часть: Ethernet, ARP, IPv4 и ICMPv4

Пока наш стек TCP/IP пользовательского пространства содержит минимальные реализации Ethernet и IPv4. Настало время заняться пугающим Transmission Control Protocol (TCP).

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

TCP — не особо новый протокол, первая его спецификация вышла в 1974 году2. С тех пор многое поменялось, TCP дополнился множеством расширений и исправлений3.

В этом посте мы изучим базовую теорию TCP, а также рассмотрим заголовок TCP и поговорим об установке соединения (TCP handshaking). Под конец мы продемонстрируем первую функциональность TCP в нашем сетевом стеке.

Как отправить робота на автономное патрулирование и научить его «видеть»? Разбираем реальный кейс создания роботизированной системы мониторинга на базе отечественной платформы: выбор оборудования, интеграция ИИ и примеры кода. Делимся опытом, как научить робота собирать данные, обходить препятствия и почему отказались от модной робособаки.

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

В процессорах архитектуры x86 SIMD инструкции добавляются по принципу ad hoc. Из-за такого подхода, легаси и требований обратной совместимости в x86 накопилось много проблем.

Архитектура RISC-V относительно молодая, и при её разработке учтён прошлый опыт. В основе подхода к SIMD в RISC-V заложили идею чистого векторного процессора.

В этой статье рассмотрим основные принципы работы векторного процессора и базовые векторные операции с памятью и арифметикой.

Хабр, привет! Меня зовут Мария Недяк, я специализируюсь на разработке харденингов нашей собственной микроядерной операционной системы «Лаборатории Касперского» KasperskyOS. Если вкратце: мы стараемся сделать любые атаки на нашу ОС невозможными — или хотя бы очень дорогими :-)

Один из главных инструментов в нашей нелегкой работе — «канарейка» (ну или Stack Canary), которая защищает от базовой атаки переполнения стека. Лично я к работе с этой птичкой уже давно привыкла — набила руку во время многократных CTF-турниров, где без такого харденинга было никуда… Этот бэкграунд очень пригодился мне в «Лаборатории Касперского», когда перед нашей командой встала задача усилить «канарейку» в KasperskyOS.

В статье я подробно объясню, как работает Stack Canary, как ее ломают — и как от этих методов взлома защититься. Сразу скажу: тема непростая, так что для самых любопытных я оставила список полезной литературы в конце текста. Поехали!

Написание собственного стека TCP/IP поначалу может показаться пугающей задачей. И в самом деле, за свой тридцатилетний срок жизни TCP впитал в себя множество спецификаций. Однако базовая спецификация остаётся относительно компактной1 — из важных частей в ней можно выделить парсинг заголовков TCP, машину состояний, отслеживание перегрузок и вычисление таймаута повторной передачи.

Самые распространённые протоколы слоя 2 и слоя 3, Ethernet и IP, скромны по сравнению с сложностью TCP. В этой серии статей мы реализуем минимальный стек TCP/IP пользовательского пространства для Linux.

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

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

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.

Сергей Каличев, старший разработчик, Angie Software

Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR. С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet, а оригинал только в архиве Интернета. Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок.

Для тех, кому удобнее читать в PDF, вот ссылки:

PDF оригинальной статьи

PDF перевода

А теперь сама статья.

Disclaimer: "чукча не писатель, чукча читатель"

UseCase 0: надоело переподключать плату с RP2040 и захотелось загружать прошивку из IDE по кнопке "Run"
UseCase 1: хочется пошаговой отладки, а не принтами.

Установил на одну из плат DebugProbe и попробовал подключиться.

Оказалось не все так просто - OpenOCD плевался на неизвестное устройство:

Контроллер Лампы для Рассады

Умный контроллер освещения на базе ESP32 с управлением через Telegram бот. Проект выходного дня для любителей растениеводства.

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