C C · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Переносимый код по стандарту C

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

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. Код читайте построчно: часть заданий проверяет вывод, часть — поиск дефекта, переносимость и безопасное исправление. После завершения откроются объяснения и профиль по 6 темам.

Вопрос 1 из 30

Что показывает макрос `__STDC_VERSION__`?

#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
_Static_assert(sizeof(int)>=2,"int range");
#endif

Номер редакции POSIX, поддерживаемой системой Версию стандарта C, заявленную выбранным режимом Точную версию и номер сборки компилятора Размер типа `long` в битах Версию реализации стандартной библиотеки

Вопрос 2 из 30

Почему успешная компиляция `typeof(x)` в режиме по умолчанию не делает код соответствующим ISO C?

typeof(x) y = x;

Выбор режима стандарта влияет только на библиотечные заголовки, а набор конструкций языка остаётся тем же ISO C допускает `typeof` только для идентификаторов, объявленных как `register` Компилятор мог принять расширение GNU; переносимость требует явного режима или изоляции расширения `typeof` является обязательной частью C17, но требует включения `<type_traits.h>` Исходный файл становится C++, если расширение используется внутри объявления переменной

Вопрос 3 из 30

Как разумно использовать возможность C23 в библиотеке, которая обязана поддерживать C17?

Безусловно использовать синтаксис C23 во всех публичных заголовках Полагаться на предупреждение, продолжая использовать неподдерживаемый синтаксис Скрыть новую возможность за проверкой и оставить совместимый путь для C17 Менять двоичный интерфейс библиотеки при каждой сборке Проверять только название операционной системы

Вопрос 4 из 30

Что изменяет выбор `-std=gnu17` по сравнению с `-std=c17`?

cc -std=gnu17 source.c

Препроцессор отключается, чтобы расширения не конфликтовали с макросами стандарта Компилятор переключает стандартную библиотеку на C23 независимо от заголовков системы Меняется только уровень оптимизации, а набор допустимого синтаксиса остаётся чистым C17 Все внешние библиотеки связываются статически без дополнительных флагов Разрешается диалект GNU с расширениями поверх C17, что может уменьшить переносимость исходника

Вопрос 5 из 30

Почему стандарт языка и стандарт системного API — не одно и то же?

POSIX заменяет компилятор и определяет синтаксис языка Стандарт C описывает внутреннее устройство ядра Linux У языка C вообще нет стандартной библиотеки Версии стандарта языка и системного API всегда обязаны совпадать ISO C задаёт язык и стандартную библиотеку, а POSIX и ОС добавляют системные интерфейсы

Вопрос 6 из 30

Гарантирует ли стандарт C, что `int` имеет ровно 32 бита?

Ровно 32 бита гарантируются только фактом запуска 64-битной операционной системы Да: стандарт фиксирует 32 бита для `int` на всех размещённых и встроенных реализациях Нет, потому что `int` по стандарту всегда имеет ровно 16 бит Да: начиная с C17 тип `int` обязан совпадать по ширине с `int32_t` Нет: стандарт задаёт минимальный диапазон и отношения между типами, но не точную ширину `int`

Вопрос 7 из 30

Почему `%lu` не является переносимым форматом для size_t?

size_t n = get_count();
printf("%lu\n", n);  /* непереносимый вариант */

`size_t` является знаковым типом, поэтому `%lu` выводит отрицательные размеры неверно `size_t` не обязан быть `unsigned long`; стандартный спецификатор для него — `%zu` Семейство `printf` не поддерживает размеры объектов без предварительного преобразования к строке `size_t` совпадает с `unsigned long` на всех POSIX-платформах и `%lu` всегда переносим в пределах POSIX Достаточно привести `n` к `unsigned long` перед передачей: `printf("%lu", (unsigned long)n)`

Вопрос 8 из 30

В какой реализации тип `uint32_t` может отсутствовать?

Только если реализация не поддерживает `stdio` Если `CHAR_BIT` равен восьми Когда нет беззнакового целого типа ровно 32 бита без лишних битов заполнения В C23 этот тип удалён из стандартной библиотеки Никогда: `uint32_t` обязателен для любой реализации C

Вопрос 9 из 30

Как печатать `uint64_t` переносимо?

#include <stdint.h>
#include <stdio.h>

uint64_t value = get_value();
printf(/* выбрать переносимый формат */, value);

Привести к int Через strlen Использовать макрос PRIu64 из inttypes.h Всегда `%llu` Использовать `%p`

Вопрос 10 из 30

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

char c=(char)0xFF;
if(c<0) ... /* зависит от реализации */

Знаковость задаётся единицей трансляции и может различаться между функциями одного файла Диапазон обычного `char` всегда совпадает с диапазоном `unsigned char`, различается только формат вывода Знаковость `char` задаёт реализация; для байтов нужен `unsigned char` Обычный `char` обязан быть знаковым, если `CHAR_BIT` равен восьми Знаковость выбирается для каждого объекта `char` по значению, записанному при инициализации

Вопрос 11 из 30

Почему проверка `#ifdef __linux__` хуже проверки наличия конкретной возможности?

#ifdef __linux__
    use_posix_memalign();
#else
    use_fallback_allocator();
#endif

Проверка названия ОС достаточна для системных вызовов, но неприменима лишь к функциям стандартной библиотеки Макрос платформы сообщает версию ядра, но не версию компилятора, поэтому условие надёжно только для заголовочных функций Название ОС не гарантирует наличие и версию конкретного интерфейса Директива `#ifdef` различает только пользовательские макросы и не может проверять предопределённые имена Наличие функции следует определять во время выполнения; проверка при настройке сборки не может учитывать заголовки и библиотеку

Вопрос 12 из 30

Какой риск у ветви, которая не собирается в основной среде разработчика?

Риск ограничен комментариями: токены неактивной ветви всё равно проверяются компилятором Определяющий макрос удаляет неактивную ветвь из репозитория после первой успешной сборки Код ветви может устареть относительно API, хотя препроцессор продолжает корректно исключать его Неактивная ветвь проходит синтаксический анализ, но её предупреждения скрываются до выбора конфигурации Она может годами накапливать синтаксические и смысловые ошибки

Вопрос 13 из 30

Почему конфигурационные возможности удобнее задавать макросами 0 или 1 и проверять через `#if`?

#define FEATURE_TLS 0
#ifdef FEATURE_TLS
/* ошибочно включится */
#endif

Так компилятор всегда заметно быстрее обрабатывает файл Стандарт C требует, чтобы любой конфигурационный макрос был равен 0 или 1 Единая схема 0/1 не даёт спутать «определено как 0» с «возможность включена» Макрос препроцессора не может иметь значение ноль При схеме 0/1 директива `#endif` больше не нужна

Вопрос 14 из 30

Как уменьшить количество платформенных `#ifdef` в основной логике программы?

Добавить отдельные `#ifdef` в каждую функцию бизнес-логики Вынести различия в узкий платформенный модуль с единым интерфейсом Собрать все различия в один огромный публичный заголовок Скопировать весь проект для каждой платформы Заменить все условные ветви оператором `goto`

Вопрос 15 из 30

Что неверно в проверке порядка байтов через нестандартный предопределённый макрос без запасного пути?

#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
  ...
#endif

Препроцессор выполняется после линковки и не влияет на этот код Имена таких макросов зависят от компилятора; нужен конфигурационный слой или явное декодирование Все современные платформы используют только обратный порядок байтов Порядок байтов невозможно определить ни одним переносимым способом Предопределённые макросы порядка байтов одинаковы у всех компиляторов

Вопрос 16 из 30

Почему бинарный режим файла важен на некоторых системах?

FILE *f=fopen(path,"rb");

Текстовый режим преобразует прочитанные числа к `float`, а бинарный сохраняет объявленный тип Текстовый режим является расширением POSIX, а стандартный `fopen` определяет лишь бинарный Буква `b` меняет значения байтов на POSIX и игнорируется на Windows Бинарный режим шифрует данные перед передачей файловой системе На некоторых системах текстовый режим преобразует окончания строк и учитывает специальные маркеры

Вопрос 17 из 30

Почему нельзя одинаково соединять компоненты пути строкой `dir + "/" + name` на всех платформах?

Правила путей различаются; нужен платформенный слой Путь не является текстовыми данными Любое имя файла уже является абсолютным путём Строки в C вообще нельзя объединять Символ `/` запрещён стандартом ISO C

Вопрос 18 из 30

Как текущая локаль может повлиять на `strtod`?

double x=strtod("1.25",&end); /* смысл точки зависит от locale */

Локаль никак не влияет на `strtod` `strtod` всегда принудительно выбирает UTF-8 Локаль меняет размер типа `double` Локаль учитывается только во время компиляции Локаль меняет десятичный разделитель и разбор текста

Вопрос 19 из 30

Почему `time_t` нельзя безусловно сериализовать как знаковое 32-битное число?

Значения времени запрещено передавать между процессами или хранить в файлах `time_t` по определению является строкой, содержащей дату в локальном формате Стандарт гарантирует ровно 64 бита и знаковость `time_t`, поэтому 32-битный формат лишь теряет место `htonl` принимает любой `time_t` и автоматически учитывает эпоху и единицы измерения Тип, диапазон и семантика `time_t` зависят от реализации; протокол должен задать ширину, эпоху и единицу отдельно

Вопрос 20 из 30

Что переносимо можно утверждать о `rename`, если имя назначения уже существует?

Одинаковую атомарную замену на любой файловой системе Гарантированную синхронизацию нового файла с физическим диском Гарантию, что во время операции сеть недоступна Стандарт C не задаёт единой семантики замены: поведение зависит от реализации Безусловное сохранение всех прав и владельца заменяемого файла

Вопрос 21 из 30

Зачем собирать переносимый код и GCC, и Clang?

gcc -std=c17 -Wall -Wextra -pedantic ...
clang -std=c17 -Wall -Wextra -pedantic ...

Чтобы компиляция одного файла шла вдвое быстрее Разные компиляторы выявляют расширения и зависимость от UB Две сборки полностью заменяют выполнение тестов GCC компилирует только C, а Clang — только C++ Чтобы изменить порядок байтов целевой машины

Вопрос 22 из 30

Что именно проверяет `_Static_assert(sizeof(uint32_t) * CHAR_BIT == 32, ...)`?

_Static_assert(sizeof(uint32_t)*CHAR_BIT==32,"need 32 bits");

Фактическую ширину `uint32_t` в битах через `sizeof * CHAR_BIT` Что платформа использует обратный порядок байтов Что тип `int` совпадает с `uint32_t` Что программа будет выполняться быстрее Что любой байт реализации всегда состоит из восьми бит

Вопрос 23 из 30

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

Кросс-сборка или CI целевой архитектуры с эталонными байтами Добавить `volatile` ко всем сериализуемым значениям Сравнивать числовые значения указателей Дважды запустить ту же x86-сборку Вручную переставить байты в одном месте исходника

Вопрос 24 из 30

Почему 32-битная сборка полезна даже на 64-битном хосте?

cc -m32 -std=c17 test.c -o test32

Находит допущения о размерах указателей, `long` и `size_t` Она запрещает динамическое выделение и поэтому отделяет ошибки кучи от ошибок стека Она проверяет другую модель данных, но не выявляет сохранение указателей в слишком узком целом типе Она доказывает отсутствие ошибок памяти, если приложение успешно проходит полный набор тестов Она воспроизводит двоичный интерфейс Windows независимо от хоста и выбранной библиотеки C

Вопрос 25 из 30

Что должно входить в тесты переносимой сериализации?

assert(memcmp(encoded,"\x01\x02\x03\x04",4)==0);

Эталонные байты, границы и независимое декодирование Сравнение необязательных байтов заполнения структуры между двумя запусками одной программы Снимок `sizeof` каждого типа без проверки конкретных байтов внешнего формата Только круговой тест: закодировать и тут же декодировать теми же функциями на одной архитектуре Проверка числовых значений адресов объектов после сериализации и обратного чтения

Вопрос 26 из 30

Почему `write(fd, &key, sizeof key)` может записать в файл больше секретных данных, чем ожидает программист?

Проблема возникает только при записи структур с битовыми полями Ядро дублирует запись в системный журнал при использовании `write` с пользовательскими структурами Байты заполнения между полями могут содержать неинициализированные данные стека или кучи Функция `write` добавляет заголовок с версией структуры перед самими данными `uint64_t secret` после записи превращается в строковое представление числа

Вопрос 27 из 30

Можно ли сохранить указатель как `uintptr_t` и восстановить его в другом запуске процесса?

Можно после преобразования собственной функцией `htonll` Можно, если адрес не равен нулю Да, значение `uintptr_t` переносимо между любыми запусками Можно на любой 64-битной операционной системе Нет, адрес процесса не является устойчивым идентификатором

Вопрос 28 из 30

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

int x=-4;
int y=x>>1; /* реализация определяет результат */

Всегда полагаться на арифметический правый сдвиг Добавить `-O0`, чтобы результат стал стандартным Преобразовать значение к `float` перед сдвигом Не полагаться на результат: взять unsigned или задать операцию явно Сравнить адрес переменной с нулём

Вопрос 29 из 30

Почему тип `long` плохо задаёт 64-битное поле публичного двоичного API?

`long` не является целым типом В LP64 `long` обычно 64-битный, а в LLP64 — 32-битный Публичный API не может принимать числовые значения Единственная проблема — порядок байтов `long` всегда имеет ширину 128 бит

Вопрос 30 из 30

Что надёжнее для проверки переполнения при преобразовании внешнего uint64_t в size_t?

uint64_t value = read_external_u64();
size_t n;
/* выбрать проверку, которую нужно выполнить до преобразования value в size_t */

Привести к int и сравнить Просто выполнить приведение типа Проверить errno после приведения типа Использовать memcpy Сначала сравнить с SIZE_MAX, затем привести

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу