Компилятор, Make и линковщик — бесплатный тест онлайн

Вопрос 1 из 30

Что дают флаги `-std=c17 -pedantic`?

cc -std=c17 -Wall -Wextra -pedantic file.c

Отключает все предупреждения, кроме синтаксических ошибок Принудительно связывает стандартную библиотеку статически Автоматически переписывает все нестандартные конструкции в переносимый C17 Включает AddressSanitizer и UndefinedBehaviorSanitizer Выбирает C17 и просит диагностировать расширения вне выбранного стандарта

Вопрос 2 из 30

Почему `-Werror` стоит включать как осознанную политику проверочной сборки, а не как универсальное лекарство?

`-Werror` превращает некоторые корректные выражения C в выражения с неопределённым поведением Настоящие ошибки трансляции становятся предупреждениями, поэтому их сложнее отличить в журнале сборки При `-Werror` компилятор обязан отключить оптимизацию, чтобы предупреждения не зависели от уровня `-O` Новые предупреждения могут ломать сборку; группы и обновление политики нужно контролировать Флаг применяет только предупреждения из `-Wall`, игнорируя явно включённые группы диагностики

Вопрос 3 из 30

Какой набор параметров GCC или Clang лучше всего подходит для первого расследования обращения после освобождения памяти?

#include <stdlib.h>

int main(void) {
    int *p = malloc(sizeof *p);
    free(p);
    return *p; /* требуется диагностическая сборка */
}

`-g -O1 -fsanitize=leak`, находящий утечки, но не само обращение к освобождённому блоку `-g -O1 -fsanitize=thread`, предназначенный прежде всего для гонок данных `-g -O1 -fstack-protector-strong`, проверяющий лишь часть повреждений стека `-g -O1 -fno-omit-frame-pointer -fsanitize=address,undefined` `-g -O1 -fsanitize=undefined` без инструментирования адресов памяти

Вопрос 4 из 30

Почему сбой только при `-O2` ещё не доказывает ошибку оптимизатора?

Оптимизатор может ошибаться, но сам факт сбоя при `-O2` не отличает дефект компилятора от дефекта программы Оптимизация может проявить уже существующее неопределённое поведение, гонку или неверное предположение о псевдонимах При `-O2` вызовы выделения памяти удаляются как несущественные, если результат сразу проверяется Требования стандарта C применяются только к неоптимизированной сборке, а выпускной код им следовать не обязан Уровень `-O2` меняет все `int` на `long`, поэтому сбой чаще связан с несовпадением размеров типов

Вопрос 5 из 30

Зачем фиксировать точную команду компиляции в отчёте о дефекте?

cc --version
cc -v -std=c17 -O2 -DNDEBUG ...

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

Вопрос 6 из 30

Почему определение переменной в заголовке приводит к `multiple definition`?

/* bad.h */
int counter=0;

Объект объявлен с `extern`, но определён ровно в одном `.c`-файле В заголовке установлен include guard, поэтому символ определён дважды Определение внешнего объекта из заголовка попадает в несколько единиц трансляции Один и тот же прототип функции включён в два исходных файла Компонуемые объектные файлы не содержат ни одного символа

Вопрос 7 из 30

Что показывает `U parse_config` в выводе nm для main.o?

nm main.o | grep parse_config
                 U parse_config

Символ определён локально Это адрес 0 Символ удалён Функция inline Нужно внешнее определение `parse_config`

Вопрос 8 из 30

Почему несовпадающие прототипы в разных `.c`-файлах опасны, даже если линковщик нашёл одно имя?

/* a.c */ long f(long);
/* b.c */ int f(int x){ return x; }

Имя внешнего символа обычно не кодирует полный C-тип, поэтому единицы трансляции могут использовать разные соглашения На машинном уровне C-функции передают только адреса, так что различие `int` и `long` несущественно Прототипы используются только редактором и не влияют на передачу аргументов или возвращаемого значения Линковщик обычно видит типы из исходных файлов и отклоняет несовпадение ещё до разрешения символа Несовпадающие объявления возможны лишь для `static`-функций, которые не участвуют в компоновке

Вопрос 9 из 30

Как изменится видимость функции `parse_line` из-за `static` на уровне файла?

static int parse_line(const char *s){...}

Тело функции размещается только в стеке текущего потока и исчезает после возврата Функцию можно вызвать не более одного раза из каждой единицы трансляции Линковщик обязан удалить функцию, даже если она вызывается из того же `.c`-файла Внутреннее связывание автоматически делает доступ к общим объектам потокобезопасным Имя имеет внутреннее связывание и не экспортируется

Вопрос 10 из 30

Зачем объектному файлу записи перемещений?

Чтобы выбрать локаль для строковых литералов Чтобы объектный файл мог сам вызывать `malloc` до запуска программы Чтобы хранить полный исходный текст рядом с машинным кодом Чтобы сжать несколько объектных файлов в статический архив Чтобы линковщик скорректировал ссылки после окончательного размещения секций и символов

Вопрос 11 из 30

Почему изменение `header.h` не приводит к пересборке `main.o` в этом правиле?

main.o: main.c
	$(CC) -c main.c -o main.o

Заголовок обязан иметь расширение `.hpp`, иначе `make` его игнорирует Правило не объявляет зависимость `main.o` от заголовка или созданного файла `.d` Любой объектный файл автоматически является фиктивной целью `.PHONY` `make` вообще не умеет отслеживать изменения заголовочных файлов Для пересборки нужно удалить установленный компилятор

Вопрос 12 из 30

Что обозначают `$@` и `$<` в обычном шаблонном правиле?

%.o: %.c
	$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@

Все цели и все файлы Имя цели и первая зависимость Каталог и расширение Текущий pid и exit code Компилятор и флаги

Вопрос 13 из 30

Почему рецепт с `cd build` на одной строке и `cmake ..` на следующей может не работать как ожидается?

configure:
	cd build
	cmake ..

Строки рецепта по умолчанию запускаются в отдельных оболочках, поэтому рабочий каталог не сохраняется Относительный путь `build` вычисляется от корня файловой системы, а не от каталога проекта Причина в отступе второй строки: один знак табуляции меняет каталог для всего рецепта `cmake` выполняется до `cd`, потому что make сортирует команды рецепта по имени Команда `cd` разрешена лишь в функциях make и не передаётся оболочке

Вопрос 14 из 30

Какой дефект зависимости может проявиться только при `make -j`?

app: main.o generated.h

main.o: main.c
	$(CC) -c main.c -o main.o

# main.c включает generated.h

Любая параллельная сборка принципиально неверна для программ на C `make -j` полностью игнорирует времена изменения файлов Все объектные файлы при параллельной сборке получают одно имя Флаг `-j` отключает вызов компилятора и запускает только линковщик `main.o` может начать собираться до готовности `generated.h`, потому что зависимости нет

Вопрос 15 из 30

Зачем объявлять `clean` как `.PHONY`?

.PHONY: clean
clean:
	rm -f app *.o

Чтобы после очистки удалить и сам Makefile как источник устаревших зависимостей Чтобы одноимённый файл не помешал выполнить цель Чтобы рецепт `clean` автоматически запускался перед каждой обычной целью сборки Чтобы `make` не сравнивал время выполнения команды с временем изменения зависимостей Чтобы имя цели разрешалось с пробелами и не требовало экранирования в оболочке

Вопрос 16 из 30

Почему порядок `main.o -lmath` может работать, а `-lmath main.o` — нет?

cc main.o -L. -lmath -o app

Порядок объектных файлов и библиотек не влияет на разрешение символов ни у одного распространённого линковщика Флаг `-l` распознаётся только в конце команды независимо от того, статическая библиотека или динамическая Перестановка архива изменяет двоичный интерфейс функций, поэтому имена символов перестают совпадать При обычной работе со статическим архивом линковщик извлекает его члены для уже известных неразрешённых символов Стандарт языка C требует помещать единицу с `main` перед каждой библиотекой в командной строке

Вопрос 17 из 30

Что делает `ar rcs libutil.a parse.o io.o`?

ar rcs libutil.a parse.o io.o

Динамически загружает объекты Компилирует заголовки Создаёт архив и индексирует его символы Удаляет секции Запускает программу

Вопрос 18 из 30

Почему открытая структура в публичном заголовке усложняет совместимость ABI?

/* public_api.h */
typedef struct context {
    int state;
    size_t capacity;
    void *data;
} context;

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

Вопрос 19 из 30

Что произойдёт, если в архиве нет объекта с требуемым `parse`?

Программа запустится без parse Функция будет inline Вызов станет NULL автоматически Компилятор создаст функцию Линковщик сообщит `undefined reference`

Вопрос 20 из 30

Почему внутренние символы библиотеки полезно скрывать?

Сокрытие запрещает использовать `static`, оставляя единый механизм управления видимостью Сокращаются внешний ABI и риск конфликтов имён Архив статической библиотеки становится текстовым и легче сравнивается между сборками Скрытые функции компилируются без оптимизации, что упрощает отладку библиотеки Сокрытие не даёт библиотеке C экспортировать собственный `malloc` в зависимый процесс

Вопрос 21 из 30

Как увидеть результат раскрытия макросов перед компиляцией?

cc -E -dD source.c > source.i

`cc -c file.c`, создающая объектный файл без связывания `nm file.o`, читающая уже созданную таблицу символов `cc -E file.c`, останавливающаяся после препроцессирования `ar t lib.a`, перечисляющая члены статического архива `cc -S file.c`, выдающая ассемблер после компиляции

Вопрос 22 из 30

Что делает команда `make -n app`?

make -n app

Удалит сборку Запустит n потоков Проверит память Покажет команды, не запуская их Создаст dependency file

Вопрос 23 из 30

Зачем в Makefile используют флаги `-MMD -MP`?

CFLAGS += -MMD -MP
-include $(OBJ:.o=.d)

Создаёт зависимости заголовков и фиктивные цели для удалённых файлов Они добавляют профилирование времени выполнения каждой функции Они переключают диалект языка на следующую версию стандарта Они собирают объектные файлы в статический архив Флаги включают динамическую компоновку вместо статической

Вопрос 24 из 30

Как карта компоновки линковщика помогает при неожиданно большом бинарнике?

cc ... -Wl,-Map,app.map -o app

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

Вопрос 25 из 30

Сборка подхватывает неожиданную копию `config.h`. Какой набор действий точнее всего покажет фактический путь заголовка?

cc -Ivendor/include -Iinclude -c main.c

Посмотреть дерево включений (`-H`), пути поиска (`-v`) и при необходимости результат препроцессора (`-E`) Использовать только `-nostdinc`, исключив системные каталоги и одновременно изменив условия сборки Добавить `-MMD -MP`: файл зависимостей покажет часть включений, но не порядок поиска и раскрытый текст Сравнить команды `nm` для двух объектных файлов после компиляции Поменять местами каталоги `-I` и считать исчезновение ошибки достаточным доказательством

Вопрос 26 из 30

Почему `make NAME="$(user_input)"` опасно при подстановке в рецепт?

package:
	tar -czf $(NAME).tgz build/

Недоверенное значение после подстановки становится частью команды оболочки и способно изменить её синтаксис Значения командной строки доступны только условиям make и не попадают в рецепты make экранирует кавычки и разделители при подстановке в рецепт Риск связан с разделением имени пробелами, но подстановка команд и перенаправления остаются данными Переменные make хранят числовые значения, поэтому строка превращается в код возврата

Вопрос 27 из 30

Что означает `-Wl,-z,relro,-z,now` на поддерживающей ELF-платформе?

cc app.o -Wl,-z,relro,-z,now -o app

Полностью отключает все записи перемещений в объектном файле Принудительно связывает все зависимости статически Шифрует исполняемый файл ключом линковщика Включает AddressSanitizer для итогового процесса Просит усилить защиту таблиц перемещений и разрешить динамические символы при запуске

Вопрос 28 из 30

Почему относительный rpath вроде `.` опасен?

Динамический загрузчик не понимает точки rpath используется компилятором для заголовочных файлов Только потому что путь короткий Библиотека может загрузиться из контролируемого текущего каталога Он увеличивает stack

Вопрос 29 из 30

Как подтвердить, что защитные свойства действительно появились в итоговом бинарнике?

$(CC) $(CFLAGS) main.o -o app $(LDFLAGS)
# Нужно проверить свойства именно файла app.

Проверить свойства итогового файла через `readelf` или специализированный анализатор Сравнить дату изменения бинарника с датой исходного кода Прочитать только флаги в Makefile, не исследуя реальный результат Выполнить `make clean` и считать удаление объектов подтверждением Посмотреть расширение имени исполняемого файла

Вопрос 30 из 30

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

Язык C запрещает запуск внешних программ во время сборки Генератор создаёт только текст и потому не способен причинить вред Процессы генерации кода технически не могут открывать сеть Он выполняется с правами среды сборки и может читать секреты, сеть и файлы Риск появляется лишь после установки готового приложения пользователем