C *

В этом посте разобраны некоторые фокусы, причуды и фичи языка C (некоторые из них – весьма фундаментальные!), которые, казалось бы, могут сбить с толку даже опытного разработчика. Поэтому я потрудился сделать за вас грязную работу и (в произвольном порядке) собрал некоторые из них в этом посте. Примеры сопровождаются ещё более вольными краткими пояснениями и/или листингами (некоторые из них цитируются).

Конечно же, здесь я не берусь перечислять абсолютно всё, так как факты из разряда «функция nan() не может устанавливать errno, поскольку в определённых ситуациях поведёт себя как strtod()» не слишком интересны.

ВНИМАНИЕ: сам факт попадания тех или иных вещей в эту подборку  не означает автоматически, что я рекомендую или, наоборот, не рекомендую ими пользоваться! Некоторые из приведённых примеров никогда не должны просачиваться за пределы списков наподобие этого, тогда как другие примеры невероятно полезны! Уверен, что могу положиться на ваш здравый смысл, дорогие читатели.

В данной статье я хотел бы вам расказать, как можно создавать свои аппаратно-независимые библиотеки для микроконтроллеров для работы с цифровыи микросхемами.

Суть создания аппаратно-независимой библиотеки состоит в том, чтобы отвязаться от того уровня абстракции (библиотеки и фреймворки), который предоставляет производитель микроконтроллеров, внутри реализуемой библиотеки. Например, для STM32 - HAL, ESP32 - ESP-IDF или Arduino, для AVR зачастую используют Arduino. Это позволит использовать одну и ту же библиотеку на различных микроконтроллерах (и не только) без изменения кода библиотеки под каждый камень.

Представляю вашему вниманию третью (заключительную) часть перевода статьи A guide to inter-process communication in Linux.

Первая часть перевода была посвящена общему введению в курс дела и механизму разделяемого хранилища (shared storage). Во второй части были рассмотрены механизмы каналов (именованных и неименованных) и очереди сообщений. В третьей части автор статьи ставит перед собой цель рассказать вам о сокетах и сигналах; подводит общие итоги по межпроцессному взаимодействию в Linux.

Приятного чтения!

Или почему не нужно бояться того, что удобно работает. Узнаем, что по этому поводу пишет стандарт, потом заглянем в реализации std::array в libc++ и libstdc++, затем посмотрим на ассемблер некоторых операций с этими объектами. Завершим всё это дело, как и полагается, бенчмаркингом.

Представлена утилита-надзиратель, что последовательность определения static функций совпадает с последовательностью объявляения static функций.

Разбираемся в Brainfuck, Пишем для него генератор кода и интерпретатор

Или рассказ о том, как я решал легкую C задачку

Однако я решил что решать эту задачу привычным методом будет скучно и я решил слегка усложнить себе задачу, чтобы поинтереснее было. Так и появилась идея написать этот код на brainfuck, а на C интерпретатор для него.

Естественно делать это голыми руками будет больно и не приятно, поэтому я решил написать генератор brainfuck кода на Java.

Привет! Меня зовут Никита Соболев, я core-разработчик языка программирования CPython, а так же автор серии видео про его устройство.

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

Под катом куча кишков питона и видео на 46 минут с дополнительными кишками питона (ни один настоящий питон не пострадал при написании данной статьи).

Это невозможно! И вы будете правы, только ошибка в том, что это — реальность.
Или как сказал один человек «Это компьютерная наука. Ограничений нет. Я могу делать все, что захочу. Это всего лишь биты информации.»

У нас в организации есть обязательное правило оформления исходников, которое звучит так:

Порядок объявления С-функций должен совпадать с порядком определения С-функций.

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

Всем привет. Embox продолжает своё путешествие по отечественным микропроцессорам. В этой серии мы опишем путешествие на AMUR (MIK32). Кто не знает, это — полностью отечественный микроконтроллер К1948ВК018 на архитектуре RISC‑V, который производится в РФ на мощностях компании МИКРОН, входящей в ГК «Элемент».

Привет, Хабр! Меня зовут Давид, еще недавно я был стажером YADRO, а сейчас работаю в отделе разработки ПО поддержки сетевой аппаратной части. У нас в команде есть большой проект на более 100 000 строк, написан на C++ (и частично на С). Код переписывался много раз, а за самим проектом на правах легаси особо никто не следил: работает — не трогай. Когда я пришел в команду, у меня была задача: привести код в порядок и отловить ошибки, которые пропускает компилятор — например, возможное разыменование нулевого указателя, неинициализированные переменные или простые опечатки. 

Одним из очевидных решений было использование статического анализатора. Выбрали довольно известное коммерческое решение, но долгие прогоны не привели ни к чему дельному. Решили поэкспериментировать с другими вариантами статических анализаторов, сделав ставку на open source. Поиски привели к инфраструктуре CodeCheсker, которая предоставляет удобный интерфейс запуска и настройки статических анализаторов через аргументы командной строки. С помощью инструмента удалось достичь результатов, которые значительно превысили значения, полученные на коммерческом решении.  

Под катом расскажу, что же такое CodeCheсker, как с ним работать и почему его точно стоит попробовать на большом проекте.

Приветствую всех хабрачитателей. Если выкинуть административную работу, то моя основная деятельность на работе — поиск различных уязвимостей. Чаще всего мой инструментарий представляет собой набор каких‑то отладчиков, динамических анализаторов и прочего подобного. Но иногда приходится заниматься анализом исходного кода произвольной степени кривизны понятности. И это практически отдельный параллельный мир в области безопасности.

Под катом я расскажу об одном примере разбора небольшой проблемы в коде.

В некоторых компаниях есть внутренние требования к стилю оформления исходных кодов на Си.

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

Я решил недавно улучшить свой навык владения C, путем написания проектов. Самая первая мысль, которая пришла мне на ум — это командный интерпретатор, командная оболочка, shell проще говоря. А также я расскажу о системе сборки make, и о том, как правильно писать и документировать C-код.

В первой части мы задали базовую структуру кода, разобрались с чтением вывода и созданием процессов. А в этой части нашей задачи будет дойти с альфа-стадии на бета-стадию — то есть реализовать прочий важный функционал, такой как: минимальная поддержка плагинов; автодополнение; подсветка синтаксиса; переменные окружения, новые встроенные утилиты.

Да-да, мы превратим наш велосипед в мопед! Я вынес из прошлой статьи итоги, и попытался решить все проблемы и замечания. Продолжаем погружение в пучины разработки под Linux!

AV1 становится всё более значимым видеоформатом, которому требуется безопасный и производительный декодер. Исходя из этой идеи, мы в тандеме с командой из Immutant создали rav1d, портировав на Rust написанный на С декодер dav1d. Перед вами первая из двух статей, посвящённых решению этой задачи.

— Джош Аас, глава проекта Prossimo организации ISRG

Привет, Хабр! Сегодня я хочу поделиться своими наблюдениями и опытом по работе с различными ассемблерами. Я сам пишу на языке C и относительно редко касался темы ассемблера. Но недавно решил восполнить этот пробел в знаниях и посмотреть на различные ассемблеры. В данной статье мы не будем рассматривать ARM, AVR и другие микроконтроллерные архитектуры, а сосредоточимся исключительно на компьютерных ассемблерах. Давайте не будем судить строго, ведь это скорее исследовательский опыт, чем глубокое погружение.

Привет, Хабр! Меня зовут Евгений Буевич, я работаю в Рунити. Как-то раз у меня возникла непреодолимая потребность умножать матрицы определенного размера, смотреть, что получится и умножать опять до тех пор, пока что-нибудь не получится.

Остановился на BLIS, скомпилировал, подключил, и было мне счастье. Матрицы стали подрастать в числе и размере, скорость процесса, как ей и положено, падала в кубе от размера и кратно от числа. В конце концов стало ощущаться, что на ЦПУ 486,4 GFLOPS и ни флопсом больше, а замеры показывали, что на самом деле их около 350.

Библиотека форматирования {fmt} известна своим небольшим влиянием на размер бинарников. Чаще всего её код в несколько раз меньше по сравнению с такими библиотеками, как IOStreams, Boost Format или, что иронично, tinyformat.

Давайте разберем, как можно уменьшить размер бинарников еще больше!

Представляю вашему вниманию вторую часть перевода статьи A guide to inter-process communication in Linux.

Первая часть перевода была посвящена общему введению в курс дела и механизму разделяемого хранилища (shared storage). В этой части будут рассмотрены механизмы каналов (именованных и неименованных) и очереди сообщений.

Приятного чтения!