Деннис Ритчи и C: маленький язык, большое влияние на системы

Почему C всё ещё важен

C — одна из тех технологий, с которыми большинство людей не сталкивается напрямую, но от которых зависит почти всё. Если вы пользуетесь телефоном, ноутбуком, роутером, автомобилем, смарт‑часами или даже кофемашиной с экраном, велика вероятность, что где‑то в стеке задействован C — он запускает устройство, общается с железом или делает работу достаточно быстрой, чтобы она казалась «мгновенной».

Для инженеров C остаётся практичным инструментом, потому что сочетает редкое сочетание контроля и переносимости. Он может работать очень близко к машине (чтобы управлять памятью и оборудованием напрямую), но также может переноситься между CPU и ОС с относительно небольшим переписыванием. Такое сочетание тяжело заменить.

Три области, где C всё ещё лидирует

Самый большой след C заметен в трёх областях:

• Операционные системы: ядра, базовые библиотеки, драйверы и низкоуровневые утилиты, от которых зависит остальное.
• Встраиваемые устройства: маленькие системы с жёсткими ограничениями по памяти, питанию и хранению, где предсказуемость важна.
• Участки, критичные по производительности: самые чувствительные по скорости части больших программ — там, где несколько миллисекунд или ватт имеют значение.

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

Что вы узнаете из этой статьи

Эта статья связывает точки между Dennis Ritchie, исходными целями создания C и причинами, по которым он появляется в современных продуктах. Мы расскажем о:

• кратком и читаемом фрагменте истории (включая влияние Unix),
• дизайнерских решениях, которые сделали C маленьким, но мощным,
• где C уместен сегодня — его сильные стороны и проблемы с безопасностью.

Ограничение темы

Речь идёт именно о C, а не о «всех низкоуровневых языках». C++ и Rust будут упоминаться для сравнения, но фокус — на том, что такое C, почему его проектировали так, и почему команды продолжают выбирать его для реальных систем.

Кратко о Деннисе Ритчи

Dennis Ritchie (1941–2011) — американский учёный в области вычислительной техники, наиболее известен своей работой в Bell Labs компании AT&T, исследовательской организации, сыгравшей центральную роль в ранней информатике и телекоммуникациях.

Bell Labs, Unix и новый класс системного ПО

В Bell Labs в конце 1960‑х — 1970‑х Ритчи работал с Ken Thompson и другими над исследованиями операционных систем, которые привели к появлению Unix. Thompson создал раннюю версию Unix; по мере развития системы Ритчи стал ключевым соавтором, превратив проект в то, что можно было поддерживать, улучшать и широко распространять в академии и индустрии.

Создание C для реальных систем

Ритчи также создал язык программирования C, опираясь на идеи из более ранних языков Bell Labs. C был спроектирован как практичный для написания системного ПО: он даёт программистам прямой контроль над памятью и представлением данных, при этом остаётся более читаемым и переносимым, чем работа полностью на ассемблере.

Это имело значение, потому что Unix в итоге был переписан на C. Это было не ради стиля — переписывание сделало Unix гораздо проще переносимым на новое железо и расширяемым со временем. Получился мощный цикл обратной связи: Unix давал серьёзный, требовательный кейс для C, а C позволил Unix выйти за пределы одной машины.

Почему пара Unix + C стала влиятельной

Вместе Unix и C помогли определить то, что мы сейчас называем «системным программированием»: создание ОС, основных библиотек и инструментов на языке, близком к машине, но не привязанном к одному процессору. Их влияние заметно в более поздних ОС, инструментах разработчика и соглашениях, которые многие инженеры изучают сегодня — не из‑за мифов, а потому что подход работал в масштабе.

Как проектировали C: маленький, переносимый, близкий к машине

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

От BCPL к B к C (коротко)

Dennis Ritchie не изобрёл C в вакууме. Он вырос из более ранних, простых системных языков, использовавшихся в Bell Labs.

• BCPL предлагал компактный стиль для написания утилит и системного ПО.
• B (созданный Ken Thompson) адаптировал идеи BCPL для ранней работы над Unix, но ему не хватало типов данных и структуры для более крупных систем.
• C сохранил дух «малого языка», добавив возможности, которые сделали Unix практичным для создания и поддержки на реальном железе.

Цель проектирования: тонкий слой над машиной

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

Что значит «переносимый» простыми словами

«Переносимость» означает, что тот же исходный код на C можно взять и скомпилировать на другом компьютере, и при минимальных изменениях получить то же поведение. Вместо переписывания ОС для каждого нового процессора команды могли сохранить большую часть кода и менять лишь небольшие аппаратно‑зависимые части. Такое сочетание общей логики и небольших машинно‑зависимых краёв стало прорывом, который помог Unix распространиться.

Основные идеи, делающие C быстрым

Скорость C — не магия. Это во многом результат того, как прямо он отображается на действия процессора и как мало «лишней работы» вставляется между вашим кодом и CPU.

Что производит компиляция

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

На практике компилятор производит исполняемый файл (или объектные файлы, которые затем связываются). Главное — финальный результат не интерпретируется построчно во время выполнения — он уже в форме, понятной CPU, что снижает накладные расходы.

Предсказуемый контроль, низкие накладные расходы

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

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

Ручное управление памятью: контроль с последствиями

В C используется ручное управление памятью, то есть программа явно запрашивает память (например, malloc) и явно освобождает её (free). Это нужно, потому что системное ПО часто требует детального контроля над тем, когда выделяется память, сколько и на сколько — с минимальными скрытыми накладными расходами.

Компромисс прост: больше контроля означает больше скорости и эффективности, но также больше ответственности. Если забыть освободить память, освободить дважды или использовать память после её освобождения, ошибки могут быть серьёзными и даже критичными с точки зрения безопасности.

C в операционных системах: ядра, драйверы и базовые библиотеки

ОС находятся на границе между ПО и железом. Ядро управляет памятью, планирует CPU, обрабатывает прерывания, общается с устройствами и предоставляет системные вызовы, на которые опирается всё остальное. Эти задачи не абстрактны — они про чтение/запись конкретных адресов в памяти, работу с регистрами CPU и реакцию на события в неудобные моменты.

Почему ядрам и драйверам нужен низкоуровневый доступ

Драйверам и ядрам нужен язык, который может выразить «выполнить именно это» без скрытой работы. На практике это означает:

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

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

C как выбор по умолчанию для ядер и базовых библиотек

Unix и ранние системные работы популяризовали подход, который помог сформировать наследие Ритчи: реализовать большую часть ОС на переносимом языке, сохранив аппаратно‑зависимый край тонким. Многие современные ядра всё ещё следуют этой схеме. Даже когда необходим ассемблер (код загрузки, переключения контекста), основную реализацию обычно несёт C.

C также доминирует в основных системных библиотеках — стандартная библиотека языка C, фундаментальные сетевые компоненты и низкоуровневые кусочки рантайма, от которых зависят языки более высокого уровня. Если вы пользовались Linux, BSD, macOS, Windows или RTOS, вы почти наверняка сталкивались с C‑кодом, даже не подозревая об этом.

Почему команды продолжают доверять C здесь

Привлекательность C в ОС‑работе меньше связана с ностальгией и больше с экономикой инженерии:

• Стабильные тулчейны: компиляторы, линкеры, отладчики и профилировщики зрелы и хорошо понятны
• Переносимость: одну и ту же кодовую базу на C можно поднять на новых CPU и платах с управляемыми усилиями
• Ясная модель железа: проще предсказать, что сгенерирует компилятор и как поведёт себя код в жёстких ограничениях

Существуют и другие языки — но C остаётся базой

Rust, C++ и другие языки применяются в частях ОС и дают реальные преимущества. Тем не менее C остаётся общим знаменателем: языком, на котором написано множество ядер, языком, под который проектируются низкоуровневые интерфейсы, и базисом, с которым другие системные языки должны взаимодействовать.

C в встраиваемых устройствах: маленький след и предсказуемый контроль

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

Ограничения, с которыми живут встраиваемые команды

Многие встраиваемые цели имеют килобайты (не гигабайты) RAM и ограниченную флеш‑память для кода. Некоторые работают от батареи и должны большую часть времени спать. Другие имеют дедлайны реального времени — если цикл управления мотором опоздает на несколько миллисекунд, аппарат может неправильно сработать.

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

Почему C сюда хорошо подходит

C даёт компактные бинарники с минимальными накладными расходами времени выполнения. Нет обязательной виртуальной машины, и часто можно полностью избежать динамического выделения. Это важно, когда нужно уместить прошивку в фиксированную флеш‑память или гарантировать, что устройство не «замрёт» неожиданно.

Не менее важно, что C удобно работать с железом. Встраиваемые чипы открывают периферии — GPIO, таймеры, UART/SPI/I2C — через memory‑mapped регистры. Модель C естественно отображается на это: можно читать и писать по конкретным адресам, управлять отдельными битами и делать это с минимальной абстракцией.

Характерные паттерны в реальных проектах

Много встраиваемого кода на C либо:

• Bare‑metal: без ОС — стартовый код, главный цикл и обработчики прерываний.
• RTOS‑основанный: маленькая RTOS, где задачи на C координируются через очереди, семафоры и таймеры.

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

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

«Критично по производительности» — это ситуации, где время и ресурсы — часть продукта: миллисекунды влияют на UX, CPU‑циклы — на стоимость сервера, а память — на то, уместится ли программа вообще. В таких местах C всё ещё часто выбирают, потому что он позволяет контролировать расположение данных в памяти, порядок работы и то, какие оптимизации допустимы компилятору.

Где на практике важна скорость C

C часто встречается в ядре систем с высоким объёмом работы или жёсткими задержками:

• Базы данных и движки хранения (индексация, кэширование, сжатие, выполнение запросов)
• Кодеки для аудио/видео и обработки изображений (циклы кодирования/декодирования, выполняющиеся миллиард раз)
• Сеть (обработка пакетов, прокси, TLS‑примитивы, event‑loop)
• Игровые движки (тайминг кадров, физика, стриминг ресурсов)
• Участки HPC (численные ядра, векторные рутины, собственные аллокаторы памяти)

Обычно не всё должно быть «быстрым». Чаще есть конкретные внутренние циклы, которые доминируют по времени выполнения.

«Горячая дорожка»: оптимизируйте 5%, которые съедают 95%

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

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

Работа с языками высокого уровня: расширения и FFI

Современные продукты часто мультиъязычные: Python, Java, JavaScript или Rust для большей части логики и C для критического ядра.

Распространённые подходы интеграции:

• Нативные расширения (например, C‑расширения для Python, Node‑API аддоны)
• FFI (Foreign Function Interface), где язык вызывает скомпилированные C‑функции через стабильный ABI
• C‑библиотеки как общие зависимости, используемые разными рантаймами

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

Переносимость и стандарты: почему C хорошо «путешествует»

Одна из причин быстрого распространения C — его способность «путешествовать»: одно и то же ядро языка можно реализовать на совершенно разных машинах — от крошечных микроконтроллеров до суперкомпьютеров. Эта переносимость — не магия, а результат общих стандартов и культуры написания под них.

Как стандарты сделали «C» одинаковым везде

Ранние реализации C различались у разных производителей, что усложняло обмен кодом. Ключевой перелом произошёл с ANSI C (часто C89/C90), а затем с ISO C (C99, C11, C17, C23). Не нужно запоминать версии — важно, что стандарт — это публичное соглашение о том, что делает язык и стандартная библиотека.

Что даёт стандарт на практике

Стандарт обеспечивает:

• Единые правила для языка (типы, операторы, управление потоком)
• Стандартную библиотеку с предсказуемым поведением (I/O, строки, математика, управление памятью)
• Базу, которую авторы компиляторов могут реализовать, а команды — на неё опираться

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

Где на практике ломается переносимость

Проблемы переносимости обычно появляются, когда код полагается на то, что стандарт не гарантирует:

• Неопределённое поведение: код, с которым компилятор может обращаться как угодно (включая «кажется, нормально» до тех пор, пока одна сборка не сломается). Классические примеры: чтение за пределами массива или использование неинициализированного значения.
• Предположения о размерах: int не гарантирован как 32‑битный, размеры указателей различаются. Если код тихо предполагает точные размеры, он может сломаться при смене целевой платформы.
• Платформенно‑специфичные API: вызовы функций ОС могут быть необходимы, но ограничивают, где код может работать.

Практический совет: сначала стандарт, затем тюнинг

Хорошая отправная точка — отдавать предпочтение стандартной библиотеке и держать не‑переносимый код за маленькими, чётко названными обёртками.

Также собирайте с флагами, которые толкают к переносимому, определённому C. Распространённые варианты:

• выбор режима стандарта (например: -std=c11)
• включение предупреждений (-Wall -Wextra) и серьёзное отношение к ним

Комбинация «стандарт‑вперед» и строгих сборок делает больше для переносимости, чем любая «хитрая» оптимизация.

Сложная часть: указатели, память и распространённые классы багов

Сила C — и его острый край — в том, что он позволяет работать близко к памяти. Это причина, по которой C fast и гибок, но также и причина, почему новички (и уставшие эксперты) делают ошибки, которые другие языки предотвращают.

Указатели, объяснённые как «адреса коробок»

Представьте память вашей программы как длинную улицу пронумерованных почтовых ящиков. Переменная — это коробка, в которой хранится что‑то (например, целое). Указатель — это не вещь, а адрес на бумажке, который говорит, какую коробку открыть.

Это полезно: можно передавать адрес вместо копирования содержимого, и указывать на массивы, буферы, структуры или даже функции. Но если адрес неверен, вы откроете не ту коробку.

Частые риски

• Переполнение буфера: запись за конец буфера (как запихивание лишних писем в ящик #10 и затекание в #11). Это может привести к краху или быть использовано как уязвимость.
• Use‑after‑free: освобождение блока памяти, а затем использование указателя, который всё ещё «помнит» старый адрес — хотя тот ящик мог быть переприсвоен.
• Переполнение целых: арифметика, которая «оборачивается» (например, вычисление размера становится меньше ожидаемого), что может привести к выделению слишком малого буфера и последующему переполнению.

Почему эти баги важны

Они проявляются как крахи, тихая порча данных и уязвимости безопасности. В системном коде — где часто используется C — такие ошибки влияют на всё остальное стека.

Взвешенный взгляд

C не «небезопасен по умолчанию». Он позволяет явно писать то, что вы имеете в виду. Это превосходно для производительности и низкоуровневого контроля, но легко привести к ошибкам, если не сочетать язык с аккуратными практиками, ревью и хорошими инструментами.

Как сделать C безопаснее на практике

C даёт прямой контроль, но редко прощает ошибки. Хорошая новость: «безопасный C» чаще всего не про магию, а про дисциплину, ясные интерфейсы и поручение рутинных проверок инструментам.

Масштабируемые защитные техники

Проектируйте API так, чтобы неправильное использование было затруднено. Предпочитайте функции, которые принимают размеры буферов вместе с указателями, возвращают явные коды состояния и документируют, кто владеет выделенной памятью.

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

Инструменты: ловите баги до пользователей

Современные компиляторы предупреждают о рискованных паттернах — воспринимайте предупреждения серьёзно и включайте их в CI как ошибки. Во время разработки используйте санитайзеры (address, undefined behavior, leak), чтобы выявлять OOB‑записи, use‑after‑free, переполнения целых и другие опасности.

Статический анализ и линтеры находят вещи, которые не проявляются в тестах. Fuzzing особенно эффективен для парсеров и обработчиков протоколов: он генерирует неожиданные входные данные, часто выявляющие переполнения буферов и ошибки состояний.

Практики ревью и тестирования

Код‑ревью должно явно проверять распространённые дефекты C: off‑by‑one индексирование, отсутствие NUL‑терминаторов, смешение знаковых/беззнаковых типов, неучтённые возвращаемые значения и пути ошибок, приводящие к утечкам памяти.

Тестирование важнее, когда язык не защитит вас. Unit‑тесты хороши; интеграционные тесты лучше; регрессионные тесты для ранее найденных багов — оптимальны.

Более безопасные подмножества и правила

Если проект требует жёсткой надёжности или сертификации, рассмотрите использование ограниченного «подмножества» C и письменного набора правил (например, ограничение арифметики указателей, запрет некоторых вызовов библиотек или требование обёрток). Главное — последовательность: выбирайте правила, которые команда может обеспечивать средствами инструментов и ревью, а не идеалы, остающиеся на слайдах.

C против других языков: почему команды всё ещё его выбирают

C занимает необычное пересечение: он достаточно мал, чтобы понять систему целиком, и достаточно близок к границе железа/ОС, чтобы быть «клеем», от которого зависит остальное. Это сочетание объясняет, почему команды продолжают обращаться к нему, даже если новые языки кажутся привлекательнее на бумаге.

C vs C++: разные цели, сложная совместимость, практическое смешивание

C++ добавил сильные механизмы абстракции (классы, шаблоны, RAII), сохранив в ряде случаев исходную совместимость с C. Но «совместимый» не значит «идентичный». C++ меняет правила неявных преобразований, разрешения перегрузок и даже то, что считается корректным объявлением в пограничных случаях.

В реальных продуктах часто смешивают:

• низкоуровневые модули остаются на C для стабильных ABI и простых соглашений вызова
• верхние уровни используют C++ для структурирования и безопасного управления ресурсами

Мостом служит C API: C++ код экспортирует функции с extern "C", чтобы избежать манглинга имён, и обе стороны договариваются о простых структурах данных. Так команды модернизируют постепенно, не переписывая всё.

C vs Rust (в общих чертах): безопасность выигрывает, но есть ограничения

Rust обещает безопасность памяти без GC, подкреплённую строгой системой типов и инструментарием. Для многих новых проектов он устраняет целые классы ошибок (use‑after‑free, состояния гонок).

Но внедрение стоит усилий. Команды ограничены:

• существующими C‑библиотеками, драйверами или SDK поставщиков
• компиляторами и отладчиками, верифицированными для конкретных целей
• регламентами сертификации, где важна зрелость инструментов и доказательная база
• инженерами, которые будут поддерживать код десятилетиями

Rust может взаимодействовать с C, но граница добавляет сложность, и не всякая встраиваемая цель или сборочная среда одинаково хорошо поддерживается.

Почему команды сохраняют C: наследие, сертификация, тулчейны, простота

Большая часть фундаментального кода мира написана на C, и переписывать это дорого и рискованно. C также подходит для окружений, где нужны предсказуемые бинарники, минимальные требования к рантайму и широкая доступность компиляторов — от микроконтроллеров до типичных CPU.

Выбирайте по ограничениям, а не по трендам

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

Как будет выглядеть будущее (и как учить C сегодня)

C не «уходит», но его роль становится более определённой. Он будет процветать там, где нужен прямой контроль над памятью, таймингом и бинарями — и продолжит сдавать позиции там, где важнее безопасность и скорость итерации.

Где C останется сильным

C, вероятно, останется выбором по умолчанию для:

• Ядер и низкоуровневой ОС‑работы (планировщики, менеджеры памяти, файловые системы)
• Драйверов и кода, обращающегося к железу (регистры, прерывания, жёсткие ограничения)
• Встраиваемых систем с маленькими ограничениями RAM/flash и требованиями реального времени
• Базовых библиотек и рантаймов (сжатие, крипто‑примитивы, VMs, мультимедиа), где ценится стабильный ABI и широкая портируемость

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

Где C может сократиться (и почему)

Для новой прикладной разработки многие команды предпочитают языки с более сильными гарантиями безопасности и богатыми экосистемами. Ошибки памяти (use‑after‑free, переполнение буферов) дороги, а современные продукты часто ориентированы на быструю доставку, конкуренцию и безопасные настройки по умолчанию. Даже в системном программировании некоторые новые компоненты переходят на безопасные языки — при этом C остаётся «постаментом», с которым они взаимодействуют.

Один рабочий современный штрих: C в большем продукте

Даже когда низкоуровневое ядро на C, команда обычно нуждается в окружающем софте: веб‑панели, API‑сервисы, портал управления устройствами, внутренние инструменты или мобильное приложение для диагностики. Этот верхний слой — где важна скорость итерации.

Если вам нужно быстро создать эти слои, Koder.ai может помочь: это платформа для генерации кода (React, бэкенд на Go + PostgreSQL, мобильные приложения на Flutter) через чат — удобно для быстрой прототипизации админки, просмотрщика логов или сервиса управления флотом, интегрирующегося с системой на C. Режим планирования и экспорт исходников делают практичным переход от прототипа к полноценному проекту.

Практический путь изучения C сегодня

Начинайте с основ, но учитесь так, как профессионалы используют C:

1. Синтаксис и модель данных: целые, массивы, структуры, основы указателей и как всё это отображается в памяти.
2. Инструменты сборки: компиляция и линковка, организация заголовков, простой Makefile (потом CMake).
3. Отладка: пошаговая отладка с gdb/lldb; умение читать стек‑трейсы.
4. Привычки безопасности: сборка со всеми предупреждениями, использование AddressSanitizer/UBSan и написание небольших тестов.

Если хотите больше материалов по системному программированию и путям обучения, просматривайте /blog.